@fideus-labs/ngff-zarr 0.18.1 → 0.20.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (47) hide show
  1. package/esm/browser-mod.d.ts +1 -0
  2. package/esm/browser-mod.d.ts.map +1 -1
  3. package/esm/browser-mod.js +1 -0
  4. package/esm/browser-mod.js.map +1 -1
  5. package/esm/io/hcs.d.ts.map +1 -1
  6. package/esm/io/hcs.js +11 -3
  7. package/esm/io/hcs.js.map +1 -1
  8. package/esm/io/to_ngff_zarr-browser.d.ts +2 -0
  9. package/esm/io/to_ngff_zarr-browser.d.ts.map +1 -1
  10. package/esm/io/to_ngff_zarr-browser.js +5 -2
  11. package/esm/io/to_ngff_zarr-browser.js.map +1 -1
  12. package/esm/mod.d.ts +1 -0
  13. package/esm/mod.d.ts.map +1 -1
  14. package/esm/mod.js +1 -0
  15. package/esm/mod.js.map +1 -1
  16. package/esm/schemas/coordinate_systems.d.ts +2 -2
  17. package/esm/schemas/rfc4.d.ts +9 -9
  18. package/esm/schemas/rfc4.d.ts.map +1 -1
  19. package/esm/schemas/rfc4.js +6 -0
  20. package/esm/schemas/rfc4.js.map +1 -1
  21. package/esm/types/hcs.d.ts +7 -0
  22. package/esm/types/hcs.d.ts.map +1 -1
  23. package/esm/types/hcs.js +16 -3
  24. package/esm/types/hcs.js.map +1 -1
  25. package/esm/types/rfc4.d.ts +7 -1
  26. package/esm/types/rfc4.d.ts.map +1 -1
  27. package/esm/types/rfc4.js +12 -0
  28. package/esm/types/rfc4.js.map +1 -1
  29. package/esm/types/zarr_metadata.d.ts +8 -0
  30. package/esm/types/zarr_metadata.d.ts.map +1 -1
  31. package/esm/types/zarr_metadata.js.map +1 -1
  32. package/esm/utils/from_zarr_attrs.d.ts.map +1 -1
  33. package/esm/utils/from_zarr_attrs.js +97 -3
  34. package/esm/utils/from_zarr_attrs.js.map +1 -1
  35. package/esm/utils/py_format.d.ts +18 -0
  36. package/esm/utils/py_format.d.ts.map +1 -0
  37. package/esm/utils/py_format.js +22 -0
  38. package/esm/utils/py_format.js.map +1 -0
  39. package/esm/utils/rfc4_validation.d.ts +8 -0
  40. package/esm/utils/rfc4_validation.d.ts.map +1 -1
  41. package/esm/utils/rfc4_validation.js +19 -2
  42. package/esm/utils/rfc4_validation.js.map +1 -1
  43. package/esm/utils/structural_validation.d.ts +425 -0
  44. package/esm/utils/structural_validation.d.ts.map +1 -0
  45. package/esm/utils/structural_validation.js +808 -0
  46. package/esm/utils/structural_validation.js.map +1 -0
  47. package/package.json +1 -1
@@ -0,0 +1,425 @@
1
+ /**
2
+ * Structural validation for OME-Zarr v0.4 image/multiscales metadata.
3
+ *
4
+ * Where the Zod schema validation in {@link validateMetadata} answers "is this
5
+ * shaped like OME-Zarr?", the rules in this module answer "does this obey the
6
+ * specification's structural invariants?" -- axis counts, axis ordering,
7
+ * coordinate-transformation arity, finest-to-coarsest dataset ordering, and
8
+ * OMERO channel color format. These are spec MUSTs that a JSON Schema cannot
9
+ * express.
10
+ *
11
+ * Each rule is identified by a stable, kebab-case {@link SpecRule} value that is
12
+ * part of the observable surface: the identifiers, their evaluation order, and
13
+ * the dotted-segment location strings are kept byte-for-byte identical to the
14
+ * package's Python implementation so the two stay in lockstep (a property the
15
+ * cross-language parity tests assert). Rules fail fast -- the orchestrator
16
+ * throws a {@link ValidationError} on the first violation, in canonical
17
+ * specification order.
18
+ *
19
+ * This module provides the image/multiscales rule surface -- including the
20
+ * RFC 4 anatomical-orientation checks -- plus the HCS plate/well rules, which
21
+ * operate on separate metadata objects and are dispatched by the companion
22
+ * {@link validatePlate} and {@link validateWell} entry points.
23
+ */
24
+ import { type Metadata } from "../types/zarr_metadata.js";
25
+ import type { PlateMetadata, WellMetadata } from "../types/hcs.js";
26
+ /**
27
+ * Stable, kebab-case identifiers for the structural specification rules.
28
+ *
29
+ * The string values are the observable surface -- they appear in
30
+ * {@link ValidationError.rule}, logs, and tests -- and must match the package's
31
+ * Python implementation exactly. Members are listed in canonical
32
+ * specification-MUST evaluation order.
33
+ */
34
+ export declare const SpecRule: {
35
+ /** Axis count within the v0.4 range of 2..5 inclusive. */
36
+ readonly AxisCount: "axis-count";
37
+ /** At most one `time` axis and at most one `channel` axis. */
38
+ readonly AxisType: "axis-type";
39
+ /** time before channel before space; spatial names suffix (z, y, x). */
40
+ readonly AxisOrder: "axis-order";
41
+ /** Every scale/translation vector length equals the axis count. */
42
+ readonly ScaleLengthMismatch: "scale-length-mismatch";
43
+ /** Exactly one scale per dataset; a translation must follow it. */
44
+ readonly GlobalCoordTransformAfterPerLevel: "global-coord-transform-after-per-level";
45
+ /** Datasets ordered finest to coarsest; spatial scale must not shrink. */
46
+ readonly DatasetOrderHighestToLowest: "dataset-order-highest-to-lowest";
47
+ /** Each OMERO channel color is exactly six hexadecimal digits. */
48
+ readonly OmeroChannelColorFormat: "omero-channel-color-format";
49
+ /** All spatial-axis RFC 4 orientations share one `type`. */
50
+ readonly AxisOrientationConsistentType: "axis-orientation-consistent-type";
51
+ /** If any spatial axis declares an orientation, all spatial axes do. */
52
+ readonly AxisOrientationCompleteness: "axis-orientation-completeness";
53
+ /** A v0.5 entry implies a Zarr v3 store: a leaked `zarr_format` must be 3. */
54
+ readonly ZarrFormat: "zarr-format";
55
+ /** A v0.5 entry must not retain a group-level `ome`/`multiscales` wrapper. */
56
+ readonly OmeNamespace: "ome-namespace";
57
+ /** Each well's rowIndex/columnIndex agrees with the row/column in its path. */
58
+ readonly PlateRowIndexConsistency: "plate-row-index-consistency";
59
+ /** Each well image references an acquisition when the plate declares many. */
60
+ readonly WellAcquisitionMissing: "well-acquisition-missing";
61
+ };
62
+ /** Union of the {@link SpecRule} string values. */
63
+ export type SpecRule = (typeof SpecRule)[keyof typeof SpecRule];
64
+ /**
65
+ * How much validation {@link validateStructural} performs.
66
+ *
67
+ * `"strict"` is the default and runs every structural image/multiscales rule.
68
+ * `"schema_only"` skips them -- schema validation is the separate concern of
69
+ * {@link validateMetadata}, which checks the raw attributes via Zod.
70
+ */
71
+ export declare const ValidationLevel: {
72
+ /** Skip structural rules; rely on Zod schema validation only. */
73
+ readonly SchemaOnly: "schema_only";
74
+ /** Run every structural image/multiscales rule (the default). */
75
+ readonly Strict: "strict";
76
+ };
77
+ /** Union of the {@link ValidationLevel} string values. */
78
+ export type ValidationLevel = (typeof ValidationLevel)[keyof typeof ValidationLevel];
79
+ /**
80
+ * Options controlling structural validation.
81
+ */
82
+ export interface ValidateOptions {
83
+ /**
84
+ * Validation level to run. Defaults to {@link ValidationLevel.Strict}
85
+ * (`"strict"`).
86
+ */
87
+ level?: ValidationLevel;
88
+ /**
89
+ * Whether unknown metadata fields are tolerated. Defaults to `true`,
90
+ * mirroring the parser, which warns on rather than rejects unknown fields.
91
+ */
92
+ allowUnknownFields?: boolean;
93
+ }
94
+ /**
95
+ * Raised when a structural specification rule is violated.
96
+ *
97
+ * Carries the offending {@link SpecRule} and an optional `location` identifying
98
+ * the offending metadata node in dotted-segment (JSON-Pointer-style) form, e.g.
99
+ * `multiscales[0].datasets[2].coordinateTransformations[0]`. The `message` is
100
+ * formatted as `Spec rule [<rule>] violated: <message>`.
101
+ */
102
+ export declare class ValidationError extends Error {
103
+ /** The structural rule that was violated. */
104
+ readonly rule: SpecRule;
105
+ /** Dotted-segment location of the offending metadata node, if known. */
106
+ readonly location?: string;
107
+ constructor(rule: SpecRule, message: string, location?: string);
108
+ }
109
+ /**
110
+ * Validate that the axis count is within the v0.4-permitted range.
111
+ *
112
+ * OME-Zarr v0.4 requires between 2 and 5 axes, inclusive.
113
+ *
114
+ * @param metadata - The parsed multiscales metadata to validate.
115
+ * @throws {ValidationError} With {@link SpecRule.AxisCount} when
116
+ * `metadata.axes.length` lies outside `2..5`; location `multiscales[0].axes`.
117
+ */
118
+ export declare function validateAxisCount(metadata: Metadata): void;
119
+ /**
120
+ * Validate axis-type multiplicity.
121
+ *
122
+ * At most one `time` axis and at most one `channel` axis may be present.
123
+ *
124
+ * @param metadata - The parsed multiscales metadata to validate.
125
+ * @throws {ValidationError} With {@link SpecRule.AxisType} when more than one
126
+ * `time` axis or more than one `channel` axis is present; location
127
+ * `multiscales[0].axes`.
128
+ */
129
+ export declare function validateAxisType(metadata: Metadata): void;
130
+ /**
131
+ * Validate the class ordering of axes.
132
+ *
133
+ * Axes are ranked by type (`time` < `channel` < `space`) and must be listed in
134
+ * non-decreasing rank order: every `time` axis precedes every `channel` axis,
135
+ * which precedes every `space` axis. The first adjacent pair that inverts this
136
+ * ranking is reported. Pairs involving an axis type with no rank (e.g. `array`)
137
+ * are skipped.
138
+ *
139
+ * @param metadata - The parsed multiscales metadata to validate.
140
+ * @throws {ValidationError} With {@link SpecRule.AxisOrder} for the first
141
+ * adjacent pair where a lower-ranked axis type follows a higher-ranked one;
142
+ * location `multiscales[0].axes[i+1]`.
143
+ */
144
+ export declare function validateAxisOrder(metadata: Metadata): void;
145
+ /**
146
+ * Validate the count and names of spatial axes.
147
+ *
148
+ * The `space` axes, taken in order, must be the matching-length suffix of
149
+ * `(z, y, x)`: one spatial axis must be `(x)`, two must be `(y, x)`, and three
150
+ * must be `(z, y, x)`. At most three `space` axes are permitted.
151
+ *
152
+ * @param metadata - The parsed multiscales metadata to validate.
153
+ * @throws {ValidationError} With {@link SpecRule.AxisOrder} when there are more
154
+ * than three `space` axes, or when their names are not the expected suffix of
155
+ * `(z, y, x)`; location `multiscales[0].axes` or the first offending axis.
156
+ */
157
+ export declare function validateSpatialAxisOrder(metadata: Metadata): void;
158
+ /**
159
+ * Validate that each dataset defines exactly one `scale` transform.
160
+ *
161
+ * Every dataset's `coordinateTransformations` must contain exactly one `scale`
162
+ * (the per-level voxel size). This shares the per-dataset
163
+ * coordinate-transform-shape rule identifier
164
+ * ({@link SpecRule.GlobalCoordTransformAfterPerLevel}); there is no dedicated
165
+ * identifier for the scale count.
166
+ *
167
+ * @param metadata - The parsed multiscales metadata to validate.
168
+ * @throws {ValidationError} With
169
+ * {@link SpecRule.GlobalCoordTransformAfterPerLevel} when a dataset has zero or
170
+ * more than one `scale` transform; location
171
+ * `multiscales[0].datasets[i].coordinateTransformations`.
172
+ */
173
+ export declare function validatePerDatasetScaleCount(metadata: Metadata): void;
174
+ /**
175
+ * Validate coordinate-transform vector lengths against the axis count.
176
+ *
177
+ * Every `scale` and `translation` vector -- in the global
178
+ * `coordinateTransformations` (if present) and in each dataset -- must have
179
+ * exactly one entry per axis. The first mismatch, scanned
180
+ * global-then-per-dataset, is reported. The length invariant itself lives in
181
+ * {@link transformLenMismatch}.
182
+ *
183
+ * @param metadata - The parsed multiscales metadata to validate.
184
+ * @throws {ValidationError} With {@link SpecRule.ScaleLengthMismatch} for the
185
+ * first transform whose vector length disagrees with `metadata.axes.length`;
186
+ * location identifies the offending transform.
187
+ */
188
+ export declare function validateScaleLength(metadata: Metadata): void;
189
+ /**
190
+ * Validate coordinate-transform ordering within each dataset.
191
+ *
192
+ * Within a dataset's `coordinateTransformations`, a `translation` (if present)
193
+ * must follow its `scale` -- a `scale` must never appear after a `translation`.
194
+ *
195
+ * @param metadata - The parsed multiscales metadata to validate.
196
+ * @throws {ValidationError} With
197
+ * {@link SpecRule.GlobalCoordTransformAfterPerLevel} for the first dataset
198
+ * where a `scale` follows a `translation`; location identifies the offending
199
+ * `scale`.
200
+ */
201
+ export declare function validateTransformOrder(metadata: Metadata): void;
202
+ /**
203
+ * Validate that datasets are ordered finest to coarsest.
204
+ *
205
+ * Multiscale datasets must be listed from highest resolution (finest, i.e.
206
+ * smallest spatial `scale`) to lowest (coarsest). For each adjacent pair, the
207
+ * later level's `scale` must not be smaller than the earlier level's on any
208
+ * `space` axis. Pairs whose `scale` vectors are missing or too short to index a
209
+ * spatial axis are skipped -- those shapes are the concern of
210
+ * {@link validatePerDatasetScaleCount} and {@link validateScaleLength} -- so
211
+ * this rule never indexes out of bounds.
212
+ *
213
+ * @param metadata - The parsed multiscales metadata to validate.
214
+ * @throws {ValidationError} With {@link SpecRule.DatasetOrderHighestToLowest}
215
+ * for the first adjacent pair whose later (coarser) level has a smaller spatial
216
+ * scale; location `multiscales[0].datasets[i+1]`.
217
+ */
218
+ export declare function validateDatasetOrder(metadata: Metadata): void;
219
+ /**
220
+ * Validate the color format of each OMERO channel.
221
+ *
222
+ * When OMERO rendering metadata is present, every channel `color` must be
223
+ * exactly six hexadecimal digits (RGB). This reuses the package's existing
224
+ * {@link validateColor} predicate rather than re-implementing the format check,
225
+ * surfacing its failure message through the unified {@link ValidationError}
226
+ * channel.
227
+ *
228
+ * @param metadata - The parsed multiscales metadata to validate.
229
+ * @throws {ValidationError} With {@link SpecRule.OmeroChannelColorFormat} for
230
+ * the first channel whose `color` is not six hex digits; location
231
+ * `multiscales[0].omero.channels[i].color`.
232
+ */
233
+ export declare function validateOmeroColorHex(metadata: Metadata): void;
234
+ /**
235
+ * Validate RFC 4 anatomical-orientation metadata on the spatial axes.
236
+ *
237
+ * This rule does not reimplement RFC 4; it wraps the package's existing
238
+ * logic -- {@link hasRfc4OrientationMetadata} and
239
+ * {@link validateRfc4Orientation} -- and surfaces its failures through the
240
+ * unified {@link ValidationError} channel. The parsed {@link Axis} objects are
241
+ * first rendered back to the record form those helpers expect (see
242
+ * {@link axisToValidationRecord}).
243
+ *
244
+ * Orientation is optional in RFC 4, so when no spatial axis carries it the rule
245
+ * is a no-op.
246
+ *
247
+ * @param metadata - The parsed multiscales metadata to validate.
248
+ * @throws {ValidationError} With {@link SpecRule.AxisOrientationConsistentType}
249
+ * when the spatial axes' orientations do not all share one `type`, or
250
+ * {@link SpecRule.AxisOrientationCompleteness} when orientation is defined for
251
+ * some but not all spatial axes; location `multiscales[0].axes`. The original
252
+ * RFC 4 message text is preserved. Any other failure from
253
+ * {@link validateRfc4Orientation} -- e.g. an orientation value outside the
254
+ * RFC 4 vocabulary, a schema-level concern with no dedicated structural rule
255
+ * -- propagates unchanged.
256
+ */
257
+ export declare function validateAxisOrientation(metadata: Metadata): void;
258
+ /**
259
+ * Validate that a v0.5 multiscales entry implies a Zarr v3 store.
260
+ *
261
+ * OME-Zarr v0.5 metadata MUST be backed by a Zarr v3 store
262
+ * (`zarr_format === 3`). A v0.4 dataset is always Zarr v2 and carries no
263
+ * `zarr_format`, so this rule is inert below v0.5. The parsed {@link Metadata}
264
+ * does not surface the group's `zarr_format` byte -- its authoritative on-disk
265
+ * verification is a store-backed concern -- but a `zarr_format` mis-embedded
266
+ * *inside* the multiscale entry (captured in {@link Metadata.extra}) is
267
+ * reachable here: it belongs on the enclosing Zarr v3 group, never on the entry,
268
+ * and any value other than `3` is incompatible with v0.5.
269
+ *
270
+ * @param metadata - The parsed multiscales metadata to validate.
271
+ * @throws {ValidationError} With {@link SpecRule.ZarrFormat} when v0.5 metadata
272
+ * carries a `zarr_format` other than `3` in its `extra` passthrough; location
273
+ * `multiscales[0]`.
274
+ */
275
+ export declare function validateZarrFormatForVersion(metadata: Metadata): void;
276
+ /**
277
+ * Validate that a v0.5 multiscales entry is not double-namespaced.
278
+ *
279
+ * At v0.5 the multiscales metadata lives under the top-level `ome` namespace key
280
+ * of the group's `zarr.json` attributes, with the spec `version` hoisted to
281
+ * `ome.version`. The reader unwraps that namespace into this {@link Metadata}, so
282
+ * the group-level wrapper keys -- `ome` itself and the `multiscales` array --
283
+ * must never reappear *inside* a multiscale entry. A surviving wrapper key
284
+ * (captured in {@link Metadata.extra}) means the document is double-namespaced,
285
+ * was not unwrapped, or is otherwise malformed with respect to the v0.5 `ome`
286
+ * namespacing. A v0.4 store keeps multiscales at the `.zattrs` top level with no
287
+ * `ome` wrapper, so this rule is inert below v0.5.
288
+ *
289
+ * @param metadata - The parsed multiscales metadata to validate.
290
+ * @throws {ValidationError} With {@link SpecRule.OmeNamespace} when v0.5 metadata
291
+ * retains a group-level `ome` or `multiscales` key in its `extra` passthrough;
292
+ * location `multiscales[0]`.
293
+ */
294
+ export declare function validateOmeNamespace(metadata: Metadata): void;
295
+ /**
296
+ * Validate each plate well's recorded indices against its `path`.
297
+ *
298
+ * Every `PlateWell` records a `path` of the form `"<row>/<column>"` (e.g.
299
+ * `"B/03"`) alongside numeric `rowIndex` and `columnIndex` fields. OME-Zarr v0.4
300
+ * requires these to agree: the row segment must name an entry in `plate.rows`
301
+ * whose position equals `rowIndex`, and the column segment must name an entry in
302
+ * `plate.columns` whose position equals `columnIndex`. The first offending well,
303
+ * scanned in order, is reported.
304
+ *
305
+ * @param plate - The plate metadata whose wells are validated.
306
+ * @throws {ValidationError} With {@link SpecRule.PlateRowIndexConsistency} for
307
+ * the first well whose `path` is not `"<row>/<column>"`, whose row/column
308
+ * segment is absent from `plate.rows`/`plate.columns`, or whose recorded
309
+ * `rowIndex`/`columnIndex` disagrees with that segment's position; location
310
+ * `plate.wells[i]`.
311
+ */
312
+ export declare function validatePlateWellIndexConsistency(plate: PlateMetadata): void;
313
+ /**
314
+ * Validate that well images reference an acquisition when required.
315
+ *
316
+ * When a plate declares more than one acquisition, every image in each of its
317
+ * wells must carry an `acquisition` reference so the field can be attributed to
318
+ * a specific acquisition. Plates with zero or one acquisition impose no such
319
+ * requirement, so this rule is a no-op for them. The first image missing its
320
+ * reference, scanned in order, is reported.
321
+ *
322
+ * @param plate - The plate metadata declaring the acquisitions.
323
+ * @param well - The well metadata whose images are validated.
324
+ * @throws {ValidationError} With {@link SpecRule.WellAcquisitionMissing} for the
325
+ * first `WellImage` whose `acquisition` is absent while the plate declares
326
+ * multiple acquisitions; location `well.images[i].acquisition`.
327
+ */
328
+ export declare function validateWellAcquisition(plate: PlateMetadata, well: WellMetadata): void;
329
+ /**
330
+ * Run the structural image/multiscales rules in canonical specification order.
331
+ *
332
+ * Orchestrates the per-rule `validate*` functions in this module. It is
333
+ * fail-fast: the rules run in canonical specification-MUST order and the first
334
+ * {@link ValidationError} thrown propagates to the caller -- later rules do not
335
+ * run. The rules run in this order:
336
+ *
337
+ * 1. {@link validateAxisCount}
338
+ * 2. {@link validateAxisType}
339
+ * 3. {@link validateAxisOrder}
340
+ * 4. {@link validateSpatialAxisOrder}
341
+ * 5. {@link validatePerDatasetScaleCount}
342
+ * 6. {@link validateScaleLength}
343
+ * 7. {@link validateTransformOrder}
344
+ * 8. {@link validateDatasetOrder}
345
+ * 9. {@link validateOmeroColorHex}
346
+ * 10. {@link validateAxisOrientation}
347
+ * 11. {@link validateZarrFormatForVersion}
348
+ * 12. {@link validateOmeNamespace}
349
+ *
350
+ * Rules 11 and 12 are the OME-Zarr v0.5 namespacing checks; they fire only for
351
+ * v0.5 metadata and are inert (a no-op) for v0.4.
352
+ *
353
+ * Under {@link ValidationLevel.SchemaOnly} this function returns immediately
354
+ * without running any structural rule -- shape/schema validation is the
355
+ * separate concern of {@link validateMetadata}, which checks the raw
356
+ * attributes via Zod. The default level is {@link ValidationLevel.Strict}.
357
+ *
358
+ * This orchestrator covers the image/multiscales rules, including the RFC 4
359
+ * anatomical-orientation checks ({@link validateAxisOrientation}, a no-op when
360
+ * no axis declares orientation). The HCS plate/well structural rules operate on
361
+ * separate metadata objects and are dispatched by the companion
362
+ * {@link validatePlate} and {@link validateWell} entry points.
363
+ *
364
+ * @param metadata - The parsed OME-Zarr v0.4 multiscales metadata to validate.
365
+ * @param options - Validation options; defaults to
366
+ * `{ level: "strict", allowUnknownFields: true }`.
367
+ * @throws {ValidationError} For the first structural rule violated, carrying
368
+ * the offending {@link SpecRule} and `location`. Never thrown under
369
+ * {@link ValidationLevel.SchemaOnly}, which runs no structural rule.
370
+ */
371
+ export declare function validateStructural(metadata: Metadata, options?: ValidateOptions): void;
372
+ /**
373
+ * Run the structural HCS plate rules in canonical specification order.
374
+ *
375
+ * The plate-level counterpart to {@link validateStructural}: it orchestrates
376
+ * the structural rules that operate on a parsed {@link PlateMetadata}. Like its
377
+ * image/multiscales sibling it is fail-fast -- the first {@link ValidationError}
378
+ * thrown propagates to the caller and later rules do not run. The rules run in
379
+ * this order:
380
+ *
381
+ * 1. {@link validatePlateWellIndexConsistency}
382
+ *
383
+ * Per-well image rules (e.g. acquisition references) are the separate concern
384
+ * of {@link validateWell}, called where each well's own metadata is loaded.
385
+ *
386
+ * Under {@link ValidationLevel.SchemaOnly} this function returns immediately
387
+ * without running any structural rule -- shape/schema validation is the
388
+ * separate concern of {@link validateMetadata}, which checks the raw attributes
389
+ * via Zod. The default level is {@link ValidationLevel.Strict}.
390
+ *
391
+ * @param plate - The parsed OME-Zarr v0.4 plate metadata to validate.
392
+ * @param options - Validation options; defaults to
393
+ * `{ level: "strict", allowUnknownFields: true }`.
394
+ * @throws {ValidationError} For the first structural plate rule violated,
395
+ * carrying the offending {@link SpecRule} and `location`. Never thrown under
396
+ * {@link ValidationLevel.SchemaOnly}, which runs no structural rule.
397
+ */
398
+ export declare function validatePlate(plate: PlateMetadata, options?: ValidateOptions): void;
399
+ /**
400
+ * Run the structural HCS well rules in canonical specification order.
401
+ *
402
+ * Validates a single {@link WellMetadata} in the context of its parent
403
+ * {@link PlateMetadata} -- the plate's acquisition declarations govern whether
404
+ * each well image must reference an acquisition. Fail-fast, like
405
+ * {@link validateStructural} and {@link validatePlate}. The rules run in this
406
+ * order:
407
+ *
408
+ * 1. {@link validateWellAcquisition}
409
+ *
410
+ * Under {@link ValidationLevel.SchemaOnly} this function returns immediately
411
+ * without running any structural rule -- shape/schema validation is the
412
+ * separate concern of {@link validateMetadata}, which checks the raw attributes
413
+ * via Zod. The default level is {@link ValidationLevel.Strict}.
414
+ *
415
+ * @param plate - The parsed plate metadata that owns `well`; supplies the
416
+ * acquisition context the well rules consult.
417
+ * @param well - The parsed well metadata to validate.
418
+ * @param options - Validation options; defaults to
419
+ * `{ level: "strict", allowUnknownFields: true }`.
420
+ * @throws {ValidationError} For the first structural well rule violated,
421
+ * carrying the offending {@link SpecRule} and `location`. Never thrown under
422
+ * {@link ValidationLevel.SchemaOnly}, which runs no structural rule.
423
+ */
424
+ export declare function validateWell(plate: PlateMetadata, well: WellMetadata, options?: ValidateOptions): void;
425
+ //# sourceMappingURL=structural_validation.d.ts.map
@@ -0,0 +1 @@
1
+ {"version":3,"file":"structural_validation.d.ts","sourceRoot":"","sources":["../../src/utils/structural_validation.ts"],"names":[],"mappings":"AAEA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AAEH,OAAO,EAGL,KAAK,QAAQ,EAGd,MAAM,2BAA2B,CAAC;AACnC,OAAO,KAAK,EAAE,aAAa,EAAE,YAAY,EAAE,MAAM,iBAAiB,CAAC;AAOnE;;;;;;;GAOG;AACH,eAAO,MAAM,QAAQ;IACnB,0DAA0D;;IAE1D,8DAA8D;;IAE9D,wEAAwE;;IAExE,mEAAmE;;IAEnE,mEAAmE;;IAEnE,0EAA0E;;IAE1E,kEAAkE;;IAElE,4DAA4D;;IAE5D,wEAAwE;;IAExE,8EAA8E;;IAE9E,8EAA8E;;IAE9E,+EAA+E;;IAE/E,8EAA8E;;CAEtE,CAAC;AAEX,mDAAmD;AACnD,MAAM,MAAM,QAAQ,GAAG,CAAC,OAAO,QAAQ,CAAC,CAAC,MAAM,OAAO,QAAQ,CAAC,CAAC;AAEhE;;;;;;GAMG;AACH,eAAO,MAAM,eAAe;IAC1B,iEAAiE;;IAEjE,iEAAiE;;CAEzD,CAAC;AAEX,0DAA0D;AAC1D,MAAM,MAAM,eAAe,GACzB,CAAC,OAAO,eAAe,CAAC,CAAC,MAAM,OAAO,eAAe,CAAC,CAAC;AAEzD;;GAEG;AACH,MAAM,WAAW,eAAe;IAC9B;;;OAGG;IACH,KAAK,CAAC,EAAE,eAAe,CAAC;IACxB;;;OAGG;IACH,kBAAkB,CAAC,EAAE,OAAO,CAAC;CAC9B;AAED;;;;;;;GAOG;AACH,qBAAa,eAAgB,SAAQ,KAAK;IACxC,6CAA6C;IAC7C,QAAQ,CAAC,IAAI,EAAE,QAAQ,CAAC;IACxB,wEAAwE;IACxE,QAAQ,CAAC,QAAQ,CAAC,EAAE,MAAM,CAAC;gBAEf,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,MAAM,EAAE,QAAQ,CAAC,EAAE,MAAM;CAQ/D;AAqFD;;;;;;;;GAQG;AACH,wBAAgB,iBAAiB,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CAS1D;AAED;;;;;;;;;GASG;AACH,wBAAgB,gBAAgB,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CAkBzD;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,iBAAiB,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CAoB1D;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,wBAAwB,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CA0BjE;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,4BAA4B,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CAerE;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,mBAAmB,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CAmC5D;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,sBAAsB,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CAkB/D;AAED;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,oBAAoB,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CAiC7D;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,qBAAqB,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CAgB9D;AA+BD;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,wBAAgB,uBAAuB,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CAqChE;AAsBD;;;;;;;;;;;;;;;;GAgBG;AACH,wBAAgB,4BAA4B,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CAarE;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,oBAAoB,CAAC,QAAQ,EAAE,QAAQ,GAAG,IAAI,CAgB7D;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,wBAAgB,iCAAiC,CAAC,KAAK,EAAE,aAAa,GAAG,IAAI,CAqD5E;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,uBAAuB,CACrC,KAAK,EAAE,aAAa,EACpB,IAAI,EAAE,YAAY,GACjB,IAAI,CAgBN;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAyCG;AACH,wBAAgB,kBAAkB,CAChC,QAAQ,EAAE,QAAQ,EAClB,OAAO,CAAC,EAAE,eAAe,GACxB,IAAI,CAoBN;AAED;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,wBAAgB,aAAa,CAC3B,KAAK,EAAE,aAAa,EACpB,OAAO,CAAC,EAAE,eAAe,GACxB,IAAI,CASN;AAED;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,wBAAgB,YAAY,CAC1B,KAAK,EAAE,aAAa,EACpB,IAAI,EAAE,YAAY,EAClB,OAAO,CAAC,EAAE,eAAe,GACxB,IAAI,CASN"}