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
//! Golden-master `insta` snapshots for the STABLE `--json` outputs.
//!
//! Closes the two `[~]` insta items in the toolkit plan (Block 2 line 399,
//! Block 5 line 484). The per-subcommand `assert_cmd` suites already assert the
//! *intent* of each command (exit codes, the path set returned, individual
//! record fields). These snapshots add the missing layer: they lock the exact
//! byte shape of the machine-facing `--json` envelope so a silent schema drift
//! (a renamed key, a reordered/added field, a formatting change, a regression
//! that emits spurious issues on a clean store) shows up as a reviewable diff
//! instead of slipping through.
//!
//! Scope discipline — only outputs that are deterministic AND carry real
//! regression value are snapshotted, all against the committed, read-only
//! `corpus-a-canonical`:
//! - `dbmd search --json` — the `file:line:text` match envelope
//! - `dbmd validate --json` — the `{scope, store, summary, issues}` report
//! - `dbmd index query --json` — full IndexRecords from the `.jsonl` sidecar
//! - `dbmd fm query --json` — same record shape via the frontmatter lens
//! - `dbmd stats --json` — the store-overview counts/sizes/types
//! - `dbmd graph backlinks --json` — the incoming-link path array
//!
//! Determinism notes (why these are safe to freeze and the rest are not):
//! - Every record/match path in the output is **store-relative** — no absolute
//! path leaks into any of the five `--dir` commands (asserted out-of-band).
//! - The `created`/`updated`/`last_touch` timestamps are *content* fields baked
//! into the committed corpus files, not values minted at runtime — so they
//! are part of the fixture and stay fixed across runs and machines.
//! - JSON object key order is structurally stable: this build of `serde_json`
//! has `preserve_order` off, so `json!`/Map serialization is `BTreeMap`
//! (alphabetical) — not incidental run-to-run luck.
//! - The one volatile field anywhere is `validate`'s `store`, which echoes the
//! `[DIR]` arg verbatim. We neutralize it by running `validate` with the
//! process CWD set to the corpus and `.` as the arg, so it serializes as the
//! fixed string `"."` — no redaction/filter needed, and the command is a
//! pure read (it writes nothing, asserted by the corpus-unchanged check in
//! the matching `assert_cmd` suites).
//!
//! Deliberately NOT snapshotted: anything with runtime-minted timestamps
//! (`fm init`, `write`, `log` append), absolute-path-bearing human/text output,
//! or temp-store ordering — those have no stable golden and would be vacuous or
//! flaky.
use ;
/// Run `dbmd <args> --json --dir corpus-a`, assert exit 0, return stdout as a
/// `String`. Used by the five commands that take the store via `--dir` and emit
/// only store-relative paths (no normalization needed).
// ── search ────────────────────────────────────────────────────────────────
/// `dbmd search "renewal" --type wiki-page --json` — the `file:line:text` match
/// envelope over the wiki-page candidate set. Exercises the structured-filter →
/// ripgrep path end to end; every `file` is store-relative.
// ── validate ────────────────────────────────────────────────────────────────
/// `dbmd validate --all --json` on the canonical store: the SWEEP report on a
/// store that MUST stay clean. Locks the `{scope:"all", store, summary, issues}`
/// envelope and the zero-issue contract. Run with CWD=corpus + arg `.` so the
/// `store` field is the fixed `"."` (the only otherwise-volatile field).
/// `dbmd validate --json` (working-set scope) on the canonical store. Same
/// envelope as `--all` but the `scope` field flips to `"working-set"`, so this
/// locks the second code path's shape. Also clean on corpus-a.
// ── index query ─────────────────────────────────────────────────────────────
/// `dbmd index query --type contact --json` — the full IndexRecords read out of
/// the `records/contacts/index.jsonl` sidecar, path-sorted. Locks the complete
/// record schema (path + summary + tags + links + every type-specific field).
// ── fm query ──────────────────────────────────────────────────────────────
/// `dbmd fm query status=active --type contact --json` — the same sidecar
/// record shape reached through the frontmatter-query lens. All four corpus
/// contacts are `status: active`, so this is the populated, path-sorted set.
// ── stats ─────────────────────────────────────────────────────────────────
/// `dbmd stats --json` — the store overview: per-layer / per-type file counts,
/// total size, orphan + broken-link counts, recognized-vs-custom types, top
/// types. Every value is derived from the committed corpus content, so the whole
/// object is a fixed fixture. `stats` takes the store as a positional `[DIR]`.
// ── graph backlinks ─────────────────────────────────────────────────────────
/// `dbmd graph backlinks wiki/projects/northstar-renewal.md --json` — the
/// incoming wiki-link array (dependents / blast radius), store-relative and
/// sorted. The renewal project page is the most-linked hub in the corpus.