light-plan 0.0.0-stage → 0.1.0

package/dist/remote/managed-comment.d.ts

@@ -0,0 +1,104 @@
+/**
+ * The managed comment — rung 5 of the degradation ladder (LP-278).
+ *
+ * When the remote body cannot carry the managed block — the remote declares
+ * `encoding: comment`, or a body write is refused at runtime — the *same block*
+ * is posted as a comment instead.  The comment body **is** the managed block:
+ * the same delimiters, the same table, the same id links, so the pull parser
+ * (`parseManagedBlock` in `managed-block.ts`) recovers it without knowing
+ * whether it arrived in a body or a comment.  The block codec stays
+ * carrier-agnostic; this module only adds the comment-shaped wrapper around it.
+ *
+ * Two facts are the whole of the design:
+ *
+ *   1. **The comment id lives in the link store** (`LinkEntry.managedCommentId`).
+ *      Without it the next push cannot find the comment and posts a second one
+ *      — the visible, annoying failure that makes people turn sync off.  The
+ *      strategy planner below turns the recorded id plus the comment capability
+ *      into exactly one action: post, edit, replace, remove or refuse.
+ *   2. **A managed comment is our output, never a human's.**  It is excluded
+ *      from comment sync in both directions: the push never re-posts it as a
+ *      user comment, and a pull never imports it as one.  `isManagedCommentBody`
+ *      is the shared test — by id where the link store knows it, by body where
+ *      the id was lost.
+ *
+ * Pure: no disk, no network, no Node imports — the planners and the web bundle
+ * carry it, exactly like `managed-block.ts`.
+ */
+import { type ManagedBlockEntry, type ManagedBlockLinks } from './managed-block.js';
+/**
+ * Render the managed comment's body.  It is the managed block itself — the
+ * delimiters are what let the next pull recognise and strip it, and they are
+ * what let `isManagedCommentBody` tell our comment from a human's.
+ */
+export declare function renderManagedComment(entries: readonly ManagedBlockEntry[], links?: ManagedBlockLinks): string;
+/**
+ * True when a comment body is a managed comment — one of our own block outputs
+ * rather than a human's prose.  The test is the codec's own parse: both
+ * delimiters present, begin before end.  Cheap enough for the pull's comment
+ * filter, and it degrades to `false` (treat as a human comment) when a human
+ * mangled the delimiters, so nothing of ours is ever mistaken for theirs.
+ */
+export declare function isManagedCommentBody(body: string): boolean;
+/**
+ * The comment capability, in the shape the strategy planner reads.  Mirror of
+ * `CommentSupport` in `capabilities.ts`, re-declared here as plain fields so
+ * this module stays import-free of the Node-only capability cache.
+ */
+export interface ManagedCommentCapability {
+    /** The provider holds comments at all. */
+    native: boolean;
+    /** A posted comment can be edited in place. */
+    editable: boolean;
+    /** A posted comment can be deleted. */
+    deletable: boolean;
+}
+/** What the next push should do about the managed comment. */
+export type ManagedCommentAction = 
+/** No entries to write and no comment exists — nothing to do. */
+{
+    kind: 'none';
+}
+/** No comment yet: post a new one. */
+ | {
+    kind: 'post';
+}
+/** A comment exists and can be edited: edit it in place. */
+ | {
+    kind: 'edit';
+    commentId: string;
+}
+/** A comment exists, cannot be edited, but can be deleted: delete + repost. */
+ | {
+    kind: 'replace';
+    commentId: string;
+}
+/** Entries went away but the comment remains: delete it. */
+ | {
+    kind: 'remove';
+    commentId: string;
+}
+/** The carrier cannot satisfy the request — report the reason. */
+ | {
+    kind: 'unavailable';
+    reason: string;
+};
+/**
+ * Decide what one push should do about a document's managed comment, from the
+ * recorded comment id, the comment capability, and whether there is anything
+ * to write.
+ *
+ * The rules, in order:
+ *
+ *   - nothing to write, no comment → `none`;
+ *   - nothing to write, a comment exists → `remove` (needs deletion);
+ *   - something to write, no comment → `post` (needs comments at all);
+ *   - something to write, a comment exists → `edit` when editable, else
+ *     `replace` (delete + repost) when deletable, else `unavailable`.
+ *
+ * A `replace` must delete the old comment first — otherwise the remote accrues
+ * one stale comment per push.  A platform that can neither edit nor delete
+ * comments can only ever post once, so a change after that is refused rather
+ * than silently dropped or duplicated.
+ */
+export declare function planManagedComment(capability: ManagedCommentCapability, existingId: string | undefined, hasEntries: boolean): ManagedCommentAction;

package/dist/remote/managed-comment.js

@@ -0,0 +1,92 @@
+/**
+ * The managed comment — rung 5 of the degradation ladder (LP-278).
+ *
+ * When the remote body cannot carry the managed block — the remote declares
+ * `encoding: comment`, or a body write is refused at runtime — the *same block*
+ * is posted as a comment instead.  The comment body **is** the managed block:
+ * the same delimiters, the same table, the same id links, so the pull parser
+ * (`parseManagedBlock` in `managed-block.ts`) recovers it without knowing
+ * whether it arrived in a body or a comment.  The block codec stays
+ * carrier-agnostic; this module only adds the comment-shaped wrapper around it.
+ *
+ * Two facts are the whole of the design:
+ *
+ *   1. **The comment id lives in the link store** (`LinkEntry.managedCommentId`).
+ *      Without it the next push cannot find the comment and posts a second one
+ *      — the visible, annoying failure that makes people turn sync off.  The
+ *      strategy planner below turns the recorded id plus the comment capability
+ *      into exactly one action: post, edit, replace, remove or refuse.
+ *   2. **A managed comment is our output, never a human's.**  It is excluded
+ *      from comment sync in both directions: the push never re-posts it as a
+ *      user comment, and a pull never imports it as one.  `isManagedCommentBody`
+ *      is the shared test — by id where the link store knows it, by body where
+ *      the id was lost.
+ *
+ * Pure: no disk, no network, no Node imports — the planners and the web bundle
+ * carry it, exactly like `managed-block.ts`.
+ */
+import { parseManagedBlock, renderManagedBlock, } from './managed-block.js';
+// ---------------------------------------------------------------------------
+// The comment body
+// ---------------------------------------------------------------------------
+/**
+ * Render the managed comment's body.  It is the managed block itself — the
+ * delimiters are what let the next pull recognise and strip it, and they are
+ * what let `isManagedCommentBody` tell our comment from a human's.
+ */
+export function renderManagedComment(entries, links) {
+    return renderManagedBlock(entries, links);
+}
+/**
+ * True when a comment body is a managed comment — one of our own block outputs
+ * rather than a human's prose.  The test is the codec's own parse: both
+ * delimiters present, begin before end.  Cheap enough for the pull's comment
+ * filter, and it degrades to `false` (treat as a human comment) when a human
+ * mangled the delimiters, so nothing of ours is ever mistaken for theirs.
+ */
+export function isManagedCommentBody(body) {
+    return parseManagedBlock(body).found;
+}
+/**
+ * Decide what one push should do about a document's managed comment, from the
+ * recorded comment id, the comment capability, and whether there is anything
+ * to write.
+ *
+ * The rules, in order:
+ *
+ *   - nothing to write, no comment → `none`;
+ *   - nothing to write, a comment exists → `remove` (needs deletion);
+ *   - something to write, no comment → `post` (needs comments at all);
+ *   - something to write, a comment exists → `edit` when editable, else
+ *     `replace` (delete + repost) when deletable, else `unavailable`.
+ *
+ * A `replace` must delete the old comment first — otherwise the remote accrues
+ * one stale comment per push.  A platform that can neither edit nor delete
+ * comments can only ever post once, so a change after that is refused rather
+ * than silently dropped or duplicated.
+ */
+export function planManagedComment(capability, existingId, hasEntries) {
+    if (!hasEntries) {
+        if (existingId === undefined)
+            return { kind: 'none' };
+        if (!capability.deletable) {
+            return { kind: 'unavailable', reason: 'the managed comment is empty and comments cannot be deleted' };
+        }
+        return { kind: 'remove', commentId: existingId };
+    }
+    if (existingId === undefined) {
+        if (!capability.native) {
+            return { kind: 'unavailable', reason: 'the remote holds no comments' };
+        }
+        return { kind: 'post' };
+    }
+    if (capability.editable)
+        return { kind: 'edit', commentId: existingId };
+    if (capability.deletable)
+        return { kind: 'replace', commentId: existingId };
+    return {
+        kind: 'unavailable',
+        reason: 'the managed comment exists but cannot be edited or deleted',
+    };
+}
+//# sourceMappingURL=managed-comment.js.map

package/dist/remote/managed-comment.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"managed-comment.js","sourceRoot":"","sources":["../../src/remote/managed-comment.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAEH,OAAO,EACL,iBAAiB,EACjB,kBAAkB,GAGnB,MAAM,oBAAoB,CAAC;AAE5B,8EAA8E;AAC9E,mBAAmB;AACnB,8EAA8E;AAE9E;;;;GAIG;AACH,MAAM,UAAU,oBAAoB,CAClC,OAAqC,EACrC,KAAyB;IAEzB,OAAO,kBAAkB,CAAC,OAAO,EAAE,KAAK,CAAC,CAAC;AAC5C,CAAC;AAED;;;;;;GAMG;AACH,MAAM,UAAU,oBAAoB,CAAC,IAAY;IAC/C,OAAO,iBAAiB,CAAC,IAAI,CAAC,CAAC,KAAK,CAAC;AACvC,CAAC;AAmCD;;;;;;;;;;;;;;;;;GAiBG;AACH,MAAM,UAAU,kBAAkB,CAChC,UAAoC,EACpC,UAA8B,EAC9B,UAAmB;IAEnB,IAAI,CAAC,UAAU,EAAE,CAAC;QAChB,IAAI,UAAU,KAAK,SAAS;YAAE,OAAO,EAAE,IAAI,EAAE,MAAM,EAAE,CAAC;QACtD,IAAI,CAAC,UAAU,CAAC,SAAS,EAAE,CAAC;YAC1B,OAAO,EAAE,IAAI,EAAE,aAAa,EAAE,MAAM,EAAE,6DAA6D,EAAE,CAAC;QACxG,CAAC;QACD,OAAO,EAAE,IAAI,EAAE,QAAQ,EAAE,SAAS,EAAE,UAAU,EAAE,CAAC;IACnD,CAAC;IAED,IAAI,UAAU,KAAK,SAAS,EAAE,CAAC;QAC7B,IAAI,CAAC,UAAU,CAAC,MAAM,EAAE,CAAC;YACvB,OAAO,EAAE,IAAI,EAAE,aAAa,EAAE,MAAM,EAAE,8BAA8B,EAAE,CAAC;QACzE,CAAC;QACD,OAAO,EAAE,IAAI,EAAE,MAAM,EAAE,CAAC;IAC1B,CAAC;IAED,IAAI,UAAU,CAAC,QAAQ;QAAE,OAAO,EAAE,IAAI,EAAE,MAAM,EAAE,SAAS,EAAE,UAAU,EAAE,CAAC;IACxE,IAAI,UAAU,CAAC,SAAS;QAAE,OAAO,EAAE,IAAI,EAAE,SAAS,EAAE,SAAS,EAAE,UAAU,EAAE,CAAC;IAC5E,OAAO;QACL,IAAI,EAAE,aAAa;QACnB,MAAM,EAAE,4DAA4D;KACrE,CAAC;AACJ,CAAC"}

package/dist/remote/mapping.d.ts

@@ -0,0 +1,282 @@
+/**
+ * Board vocabulary ↔ remote vocabulary: the type mapping (LP-268).
+ *
+ * One slice of the mapping engine (LP-254): how a board's issue types become a
+ * remote's issue types — or labels, where the provider has no native types —
+ * and back again.  The mapping is data: `mapping.types` in the remote's config
+ * block, a map from a board type name to its remote representation.  This
+ * module only applies it.
+ *
+ * Depth is never declared here.  `hierarchy` is the single source of parenting
+ * truth locally; every function takes the issue hierarchy (what
+ * `hierarchyFor(config, 'issue')` returns) and derives depth from it exactly as
+ * `typesAtDepth` does — a type is legal at the depth where the hierarchy lists
+ * it.  A second depth declaration in the remote config is the bug this
+ * arrangement exists to prevent.
+ *
+ * Pure: no disk, no network.  Everything takes its inputs and returns a value,
+ * so the mapping is testable against literals.  The sibling mappings are the
+ * same shape — declarative, driven by config, applied here: status (below),
+ * attribute in `attributes.ts` (LP-270), resource in `accounts.ts` (LP-271),
+ * then period (LP-272).
+ */
+/**
+ * One board type's remote representation, as declared under `mapping.types`.
+ *
+ * `remote` is **one** name — the remote issue type (Jira "Story", the
+ * jsonfile `type` field) or the label that marks it (GitHub, Linear).  A board
+ * type and a remote type are one-to-one in both directions: a push has one
+ * name to write, and a pull reading that name knows which board type it is.
+ * Nothing here is a list, because nothing here is a choice.
+ *
+ * That is the one way it differs from `StatusMapping` below, and the
+ * difference is real rather than cosmetic: several *remote states* genuinely
+ * mean one board status ("Done", "Won't Fix" and "Duplicate" are all the
+ * board's `done`), so a status carries a list and a `push` that says which one
+ * to write back.  No such case exists for types.
+ *
+ * **Which carrier the name lands in is the provider's business, not the
+ * mapping's.**  A provider with native issue types (Jira, jsonfile) writes it
+ * into the native type field; one without (GitHub, Linear) writes it as a
+ * label.  Declaring the carrier here as well was a redundancy: `{ type: Story,
+ * labels: [story] }` said the same thing twice, in two keys that could
+ * disagree, about a decision the provider had already made.  It also means a
+ * mapping survives a repository that later turns native issue types on — the
+ * name is the same, only where it is written moves.
+ *
+ * The declaration may be written short (`user_story: Story`) or as the object
+ * form (`user_story: { remote: Story }`); `normalizeTypeMapping` expands the
+ * shorthand to the object form, which is the only form the engine reads.
+ */
+export interface TypeMapping {
+    /** The remote name that means this board type. Never empty. */
+    remote: string;
+}
+/** The `mapping.types` block: local type name → remote representation. */
+export type TypeMappings = Record<string, TypeMapping>;
+/**
+ * Normalize one `mapping.types` value to the object form.  Accepts the bare
+ * string (`user_story: Story`) and the object form, and returns `undefined`
+ * when the value names nothing.
+ *
+ * Two **superseded** spellings are folded rather than refused, so a board
+ * written against an older shape keeps working and means what it meant:
+ * `{ type: Story, labels: [story] }` (the two carriers, before the provider
+ * was left to choose) and a list (`[Story, "User Story"]`, before types were
+ * one-to-one).  Where a fold has to choose, the native `type` wins over a
+ * label and the first entry wins over the rest — the value that was actually
+ * being written before.
+ */
+export declare function normalizeTypeMapping(value: unknown): TypeMapping | undefined;
+/**
+ * Normalize the whole `mapping.types` block, dropping entries that name no
+ * remote type.  The provider schema rejects malformed values before this runs;
+ * this is the pure spelling of the same rule for callers that read a mapping
+ * without a schema in hand.
+ */
+export declare function normalizeTypeMappings(raw: Record<string, unknown>): TypeMappings;
+/**
+ * The remote name a push writes for a board type.  Returns `undefined` when
+ * the type has no usable mapping; a default remote type must never be
+ * invented, because filing everything as "Task" is precisely the silent data
+ * loss this refuses.
+ */
+export declare function mapTypeToRemote(mappings: TypeMappings, boardType: string): string | undefined;
+/** Every remote name any mapped type claims, in declaration order. */
+export declare function claimedTypeValues(mappings: TypeMappings): string[];
+/**
+ * Board types (in hierarchy order) with no usable mapping — the list a
+ * preflight reports when it refuses to open the remote.  A mapping entry that
+ * names no remote type counts as missing.
+ */
+export declare function missingTypeMappings(mappings: TypeMappings, hierarchy: string[][]): string[];
+/** What the remote issue carries that a type could be recovered from. */
+export interface RemoteTypeObservation {
+    /** The remote's native issue type, when the provider has types. */
+    remoteType?: string;
+    /** The remote issue's labels. */
+    labels: readonly string[];
+}
+/** Why `mapTypeFromRemote` could not produce a single board type. */
+export type TypeResolutionFailure = 'unmapped' | 'depth' | 'ambiguous';
+/**
+ * The result of resolving a remote issue back to a board type.
+ *
+ * `candidates` is every board type whose mapping matched the observation, in
+ * sorted order.  When `type` is set the resolution succeeded; when it is
+ * `undefined`, `unresolved` says why:
+ *
+ * - `unmapped`   — no board type's mapping matched the observation (candidates
+ *                  is empty).
+ * - `depth`      — candidates matched, but none is legal at the document's
+ *                  depth (the remote reparented it somewhere the local
+ *                  hierarchy forbids).
+ * - `ambiguous`  — more than one candidate is legal at the depth, and the
+ *                  managed block's recorded type did not (or could not) break
+ *                  the tie.  The depth-legal contenders are `candidates`
+ *                  filtered by `hierarchy[depth]`.
+ */
+export interface BoardTypeResolution {
+    type: string | undefined;
+    candidates: string[];
+    unresolved: TypeResolutionFailure | undefined;
+}
+/**
+ * Resolve a remote issue's type back to a board type.  When the observation
+ * matches several board types the resolution disambiguates **by depth first** —
+ * the type must be legal at the document's depth — **then by the managed
+ * block's recorded type**, the tiebreaker for two types that share a depth.
+ *
+ * `recordedType` is the `type` value the managed block wrote when this issue
+ * was pushed; it is consulted only within the depth-narrowed set, so it can
+ * break a tie but never override the hierarchy.
+ */
+export declare function mapTypeFromRemote(mappings: TypeMappings, hierarchy: string[][], observation: RemoteTypeObservation, opts: {
+    depth: number;
+    recordedType?: string;
+}): BoardTypeResolution;
+/**
+ * Every board type whose mapping claims this observation, sorted — the shared
+ * answer to "what type is this remote issue?" before depth and the managed
+ * block get a say.  Each provider's translator reads it rather than filtering
+ * `mapping.types` itself, so the four of them cannot drift apart on what
+ * counts as a match.
+ */
+export declare function boardTypesMatching(mappings: TypeMappings, observation: RemoteTypeObservation): string[];
+/** One hierarchy level the remote cannot hold natively. */
+export interface DegradedLevel {
+    /** Folder depth of this level, matching `hierarchy`'s index. */
+    depth: number;
+    /** Type names that live at this level. */
+    types: string[];
+}
+/**
+ * The hierarchy levels beyond the remote's native depth — the levels whose
+ * parenting must be carried by the degradation ladder rather than a native
+ * parent field.  Their *types* still map normally; it is the nesting that
+ * degrades.
+ *
+ * `nativeDepth` is the number of levels the remote can nest, counting the root
+ * as level 1: a tracker with no hierarchy is 1, one with a single level of
+ * sub-issues (GitHub) is 2, and so on.  Levels at index `nativeDepth` and
+ * beyond are degraded.
+ */
+export declare function degradedHierarchyLevels(hierarchy: string[][], nativeDepth: number): DegradedLevel[];
+/**
+ * One board status's remote representation, as declared under `mapping.statuses`.
+ *
+ * `remote` lists every remote state that means this board status — GitHub
+ * labels, Jira workflow statuses, Linear states.  A push writes exactly one of
+ * them: `push` when it names one, otherwise the first.  `closed` records
+ * whether this status closes the remote issue; it must agree with the board
+ * status's `terminal` flag, and a disagreement is a warning.
+ *
+ * The declaration may be written short — `done: Done`, or
+ * `done: [Done, "Won't Fix", Duplicate]` — and `normalizeStatusMapping` expands
+ * the shorthand to this object form, which is the only form the engine reads.
+ */
+export interface StatusMapping {
+    /** Every remote state that means this board status. Never empty. */
+    remote: string[];
+    /** Which remote state a push writes. Defaults to `remote[0]`. */
+    push?: string;
+    /** Whether this status closes the remote issue. */
+    closed?: boolean;
+}
+/** The `mapping.statuses` block: local status id → remote representation. */
+export type StatusMappings = Record<string, StatusMapping>;
+/**
+ * Normalize one `mapping.statuses` value to the object form.  Accepts the
+ * three spellings — a single remote state (`done: Done`), a list
+ * (`done: [Done, "Won't Fix"]`), or the full object — and returns `undefined`
+ * when the value carries no usable remote state.
+ */
+export declare function normalizeStatusMapping(value: unknown): StatusMapping | undefined;
+/**
+ * Normalize the whole `mapping.statuses` block, dropping entries that carry no
+ * usable remote state.  The provider schema rejects malformed values before
+ * this runs; this is the pure spelling of the same rule for callers that read
+ * a mapping without a schema in hand.
+ */
+export declare function normalizeStatusMappings(raw: Record<string, unknown>): StatusMappings;
+/**
+ * One entry's `remote` states, read defensively.  Normalized entries always
+ * carry a list; a hand-built one that skipped the schema may carry the bare
+ * string the config also accepts (`done: { remote: Done }`), and that must
+ * read as one state — never as a string being indexed into, which would hand
+ * a push the single character `D`.
+ */
+export declare function statusStatesOf(entry: StatusMapping | undefined): string[];
+/**
+ * The remote state a push writes for a board status — `push` when declared,
+ * otherwise the first `remote` state.  Returns `undefined` when the status has
+ * no usable mapping; a default remote state must never be invented.
+ */
+export declare function mapStatusToRemote(mappings: StatusMappings, boardStatus: string): string | undefined;
+/**
+ * Whether a board status closes the remote issue, per the mapping: `true` when
+ * the entry says `closed: true`, `false` when it says `closed: false`, and
+ * `undefined` when the status is unmapped or the entry does not say — absent
+ * means "not declared", never "assume it matches `terminal`".
+ */
+export declare function isClosedRemote(mappings: StatusMappings, boardStatus: string): boolean | undefined;
+/**
+ * Board statuses with no usable mapping — the list a preflight reports when it
+ * refuses to open the remote.  A status with no key, or whose entry normalised
+ * away to nothing, counts as missing.
+ */
+export declare function missingStatusMappings(mappings: StatusMappings, boardStatusIds: readonly string[]): string[];
+/** Why `mapStatusFromRemote` could not produce a single board status. */
+export type StatusResolutionFailure = 'unmapped' | 'ambiguous';
+/**
+ * The result of resolving observed remote states back to a board status.
+ *
+ * `candidates` is every board status whose `remote` list includes one of the
+ * observed states, in sorted order.  When `status` is set the resolution
+ * succeeded; when it is `undefined`, `unresolved` says why:
+ *
+ * - `unmapped`  — no board status claims any observed state;
+ * - `ambiguous` — several board statuses each claim one observed state (the
+ *                 issue carries both "Done" and "In Progress", say).
+ */
+export interface BoardStatusResolution {
+    status: string | undefined;
+    candidates: string[];
+    unresolved: StatusResolutionFailure | undefined;
+}
+/**
+ * Resolve observed remote states back to a single board status.  A board
+ * status claims the issue when one of its `remote` states is observed; a
+ * status mapping is expected to be many-remote-states-to-one-status, so a
+ * single observed state can never be ambiguous on its own — only several
+ * observed states that claim *different* board statuses are.
+ */
+export declare function mapStatusFromRemote(mappings: StatusMappings, observed: readonly string[]): BoardStatusResolution;
+/**
+ * Remote states with no board counterpart — the reverse-direction totality
+ * the preflight reports before anything is written.  `observedRemoteStates` is
+ * the full set of states the remote actually carries (from a live listing),
+ * not the labels on one issue.
+ */
+export declare function unmappedRemoteStates(mappings: StatusMappings, observedRemoteStates: readonly string[]): string[];
+/**
+ * Where a board status's `terminal` flag and the mapping's `closed` flag
+ * disagree.  They must agree, or a push would close a non-end column (or leave
+ * an end column open) — and a pull could not recover either faithfully.
+ */
+export interface StatusClosednessMismatch {
+    status: string;
+    /** The board's `terminal` flag. */
+    terminal: boolean;
+    /** The mapping's `closed` flag (false when absent). */
+    closed: boolean;
+}
+/**
+ * Board statuses whose `terminal` flag disagrees with the mapping's `closed`
+ * flag, in both directions: terminal-but-not-closed, and closed-but-not-
+ * terminal.  `statuses` is the board's status list (`BoardConfig.statuses`).
+ */
+export declare function statusClosednessMismatches(mappings: StatusMappings, statuses: readonly {
+    id: string;
+    terminal?: boolean;
+}[]): StatusClosednessMismatch[];