@wildo-ai/saas-models 1.1.4 → 1.1.6

package/dist/esm/external-data/external-data-pipeline-pass-mode.shared.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"external-data-pipeline-pass-mode.shared.js","sourceRoot":"","sources":["../../../../src/external-data/external-data-pipeline-pass-mode.shared.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH;;;;;;;;;;GAUG;AACH,MAAM,CAAN,IAAY,4BASX;AATD,WAAY,4BAA4B;IACtC,6CAAa,CAAA;IACb,2DAA2B,CAAA;IAC3B;;;;OAIG;IACH,6CAAa,CAAA;AACf,CAAC,EATW,4BAA4B,KAA5B,4BAA4B,QASvC;AAED;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,+CAA+C,GAAG,yBAAyB,CAAC;AAEzF;;;;;;;GAOG;AACH,MAAM,CAAN,IAAY,iCASX;AATD,WAAY,iCAAiC;IAC3C;;;;OAIG;IACH,wDAAmB,CAAA;IACnB,sGAAsG;IACtG,gEAA2B,CAAA;AAC7B,CAAC,EATW,iCAAiC,KAAjC,iCAAiC,QAS5C;AAED;;;;;GAKG;AACH,MAAM,CAAN,IAAY,qCA2BX;AA3BD,WAAY,qCAAqC;IAC/C,wGAAwG;IACxG,gFAAuC,CAAA;IACvC,mFAAmF;IACnF,oFAA2C,CAAA;IAC3C,4GAA4G;IAC5G,4FAAmD,CAAA;IACnD,mHAAmH;IACnH,sFAA6C,CAAA;IAC7C;;;OAGG;IACH,0GAAiE,CAAA;IACjE,qEAAqE;IACrE,8DAAqB,CAAA;IACrB,6GAA6G;IAC7G,kGAAyD,CAAA;IACzD,qGAAqG;IACrG,wFAA+C,CAAA;IAC/C;;;OAGG;IACH,kFAAyC,CAAA;IACzC,8GAA8G;IAC9G,gFAAuC,CAAA;AACzC,CAAC,EA3BW,qCAAqC,KAArC,qCAAqC,QA2BhD;AAED;;;;;;;GAOG;AACH,MAAM,CAAN,IAAY,0BAYX;AAZD,WAAY,0BAA0B;IACpC,mHAAmH;IACnH,yDAA2B,CAAA;IAC3B,+GAA+G;IAC/G,uDAAyB,CAAA;IACzB;;;;;OAKG;IACH,qEAAuC,CAAA;AACzC,CAAC,EAZW,0BAA0B,KAA1B,0BAA0B,QAYrC;AAED;;;;GAIG;AACH,MAAM,CAAN,IAAY,0BAKX;AALD,WAAY,0BAA0B;IACpC,qEAAqE;IACrE,+CAAiB,CAAA;IACjB,qGAAqG;IACrG,6CAAe,CAAA;AACjB,CAAC,EALW,0BAA0B,KAA1B,0BAA0B,QAKrC;AAED,sDAAsD;AACtD,MAAM,CAAN,IAAY,kCAKX;AALD,WAAY,kCAAkC;IAC5C,gDAAgD;IAChD,yEAAmC,CAAA;IACnC,uGAAuG;IACvG,2DAAqB,CAAA;AACvB,CAAC,EALW,kCAAkC,KAAlC,kCAAkC,QAK7C;AAED;;;;;;;;GAQG;AACH,MAAM,CAAN,IAAY,6BAWX;AAXD,WAAY,6BAA6B;IACvC;;;OAGG;IACH,8DAA6B,CAAA;IAC7B;;;OAGG;IACH,4DAA2B,CAAA;AAC7B,CAAC,EAXW,6BAA6B,KAA7B,6BAA6B,QAWxC","sourcesContent":["/**\n * The pipeline PASS-MODE vocabulary (#1682), in its own ROOT-exported module.\n *\n * Not beside the pipeline declaration on the `@wildo-ai/saas-models/external-data` subpath, because two\n * ROOT-exported contracts carry it: the read-through audit event (`pipelinePassMode` on\n * `AuditableEvent_HttpApiReadThroughAccess_EventDataSchema`) and, through saas-backend-lib's root, the\n * pipeline run report. A nominal enum reached from a root contract must be nameable from the root\n * (`package-public-entrypoints.md`), so the boundary moved here rather than the audit field weakening to\n * a string.\n */\n\n/**\n * The two kinds of pass a pipeline runs (#1682) — and they answer different questions, which is why\n * they are two tracks on the state row rather than one cursor.\n *\n * A FULL pass reads the whole remote population (in key order, possibly across many runs) and is the\n * ONLY pass that may conclude a remote row was deleted: \"absent from a complete read\" is evidence of\n * deletion, \"absent from a read of what changed\" is not. An INCREMENTAL pass reads only what changed\n * since the pipeline's watermark, loads it, and never runs the orphan walk.\n *\n * A pipeline that declares no `incremental` runs full passes only, exactly as before.\n */\nexport enum ExternalDataPipelinePassMode {\n  FULL = 'full',\n  INCREMENTAL = 'incremental',\n  /**\n   * An OUTBOUND pipeline's pass (#1690): it reads no source and loads nothing — it SENDS the destination's owed local\n   * changes to the system of record. The only mode such a pipeline runs, and one an inbound pipeline never runs; asking\n   * for either of the other two on an outbound pipeline, or for this one on an inbound pipeline, is refused.\n   */\n  SEND = 'send',\n}\n\n/**\n * The `operationIdentifier` a pipeline RUN writes on its read-through audit row — the one value that tells a run's row\n * apart from an ordinary read-through `read` / `list` / `count` / `search` of the same event type.\n *\n * Named because two parties must agree on it and neither owns the other: the run service writes it, and the erasure\n * evidence requirement (`erasure-propagation-record` C5, #1746) selects the rows it sums `suppressedRows` over by it.\n * A literal on each side would drift the day either was edited, and the collector would then sum nothing while\n * reporting a clean window. Root-exported for the same reason the pass mode is.\n */\nexport const EXTERNAL_DATA_PIPELINE_RUN_OPERATION_IDENTIFIER = 'externalDataPipelineRun';\n\n/**\n * An operator's answer to an OUTBOUND write of unknown outcome (#2039), given through the admin door\n * (`POST /internal/admin/external-data/outbound-changes/resolve`) by someone who LOOKED in the system of record. Root-exported\n * for the pass mode's reason: the answer's audit event carries it.\n *\n * The pass never answers this itself. A write whose outcome is unknown may have landed, and for a CREATE, sending it\n * again could make the record twice, so the change waits for someone who can see the system of record.\n */\nexport enum ExternalDataOutboundUnknownAnswer {\n  /**\n   * The write landed. For a CREATE the answer carries the remote key of the record found, and the engine writes it to\n   * the local row, so later edits reach that record as updates. The change is then settled as if it had been\n   * acknowledged, and a change made since is sent next.\n   */\n  APPLIED = 'applied',\n  /** The write did not land: the change is sent again by the next pass, under a new Idempotency-Key. */\n  NOT_APPLIED = 'not-applied',\n}\n\n/**\n * Why the outbound resolution door refused an answer (#2039). Root-exported because it reaches a CLIENT: it is the\n * stable `code` on the refusal, which a console or a script branches on — so it is named here, in the models every\n * consumer can import, not inside the backend module that decides it. Each names what the operator must look at before\n * answering again.\n */\nexport enum ExternalDataOutboundResolutionRefusal {\n  /** The row has no change of unknown outcome — answered already, settled by a pass, or never unknown. */\n  NO_UNKNOWN_CHANGE = 'no-unknown-change',\n  /** An APPLIED answer to a CREATE must carry the remote key of the record found. */\n  REMOTE_KEY_REQUIRED = 'remote-key-required',\n  /** A remote key only answers an applied CREATE; an update or a not-applied answer has no record to link. */\n  REMOTE_KEY_NOT_ACCEPTED = 'remote-key-not-accepted',\n  /** The key is not one the binding's key fields can hold (its codec refused it, or it is a non-canonical alias). */\n  REMOTE_KEY_MALFORMED = 'remote-key-malformed',\n  /**\n   * ANOTHER local row already holds that remote key. Linking a second row to the record would make each row's edits\n   * overwrite the other's — the one duplicate this door could create that the pass never can. Look again.\n   */\n  REMOTE_KEY_HELD_BY_ANOTHER_ROW = 'remote-key-held-by-another-row',\n  /** The local row is gone: there is nothing to link the record to. */\n  ROW_GONE = 'row-gone',\n  /** The local row is not the owner organization's — a pipeline never sends it, so no answer applies to it. */\n  ROW_NOT_OWNER_ORGANIZATION = 'row-not-owner-organization',\n  /** The local row already holds a DIFFERENT remote key — the answer would re-point it. Look again. */\n  ROW_HOLDS_ANOTHER_KEY = 'row-holds-another-key',\n  /**\n   * The create was answered NOT applied, but the row already holds a remote key — it is linked, so the create DID land\n   * (a pass or an earlier answer recorded it). Sending it again would contradict the row. Look again.\n   */\n  ROW_ALREADY_LINKED = 'row-already-linked',\n  /** The change moved while it was being answered (a pass, another answer). Nothing was changed; list again. */\n  CHANGED_MEANWHILE = 'changed-meanwhile',\n}\n\n/**\n * What a BIDIRECTIONAL pipeline does with a row changed on BOTH sides since they last agreed (#1723) — declared per\n * pipeline (`conflictPolicy`), and chosen per row by an operator for a conflict the pipeline refused. Root-exported for the\n * pass mode's reason: the conflict's audit event carries it.\n *\n * Only fields BOTH sides own (`owner: BOTH`) can conflict: a field only the system of record owns is loaded, a field\n * only the application owns is sent, and neither ever overwrites the other side's version of the same field.\n */\nexport enum ExternalDataConflictPolicy {\n  /** The system of record's values are loaded over the local ones; the local change to those fields is discarded. */\n  REMOTE_WINS = 'remote-wins',\n  /** The local values are kept and sent over the system of record's; its change to those fields is discarded. */\n  LOCAL_WINS = 'local-wins',\n  /**\n   * Neither side's BOTH-owned fields are touched: the row is reported as a conflict, and waits for an operator to choose\n   * REMOTE_WINS or LOCAL_WINS for it (`POST /internal/admin/external-data/outbound-changes/resolve`). The default —\n   * nothing is overwritten that nobody decided to overwrite. The row's REMOTE-owned fields still load: they cannot\n   * conflict, because nothing local writes them.\n   */\n  REFUSE_AND_REPORT = 'refuse-and-report',\n}\n\n/**\n * Which side's values a RESOLVED conflict kept (#1723) — the outcome, where {@link ExternalDataConflictPolicy} is the\n * rule that chose it. What the conflict's audit row names. Root-exported for the same reason as the policy: the audit\n * event carrying it is a root-exported contract.\n */\nexport enum ExternalDataConflictWinner {\n  /** The system of record's values were loaded over the local ones. */\n  REMOTE = 'remote',\n  /** The local values were kept, and the next outbound pass sends them over the system of record's. */\n  LOCAL = 'local',\n}\n\n/** Who chose a resolved conflict's winner (#1723). */\nexport enum ExternalDataConflictDecisionSource {\n  /** The pipeline's declared `conflictPolicy`. */\n  DECLARED_POLICY = 'declared-policy',\n  /** An operator's answer for this row, through the admin door, after the declared policy refused it. */\n  OPERATOR = 'operator',\n}\n\n/**\n * What the operator reset door (`POST /internal/admin/external-data/reset`, #1734) discards. Here, root-exported, for the\n * pass mode's reason: the reset's audit event (`AuditableEvent_ExternalDataPipelineReset_EventDataSchema`) is a\n * root-exported contract that carries it.\n *\n * The door exists because the run REFUSES, deliberately, on state it cannot trust — a state row with no checkpoint\n * version, a malformed checkpoint, a membership journal that is cyclic or does not match its pass — and each refusal\n * would otherwise repeat on every scheduled tick until someone edited rows by hand. A reset is the audited way past it.\n */\nexport enum ExternalDataPipelineResetMode {\n  /**\n   * Drop the FULL pass in flight — its cursor, its checkpoint and its membership journal. The next full run starts a new\n   * pass from the beginning. The incremental track (#1682), if any, is kept: its watermark is still a true position.\n   */\n  RESTART_PASS = 'restart-pass',\n  /**\n   * Everything RESTART_PASS drops, and the incremental track too, so the next incremental pass re-reads the whole\n   * source. For a watermark that is no longer trusted — a restored source, a source whose change timestamps moved.\n   */\n  FULL_RESYNC = 'full-resync',\n}\n"]}