@mj-biz-apps/sales-core-entities-server 6.4.0 → 6.6.0

package/dist/DealEntityServer.d.ts

@@ -111,6 +111,38 @@ export declare class DealEntityServer extends DealEntity {
      */
     Save(options?: EntitySaveOptions): Promise<boolean>;
     private saveDeclared;
+    /**
+     * Is this save a status move into or out of a locking status, and therefore a close or a reopen?
+     *
+     * Null in every ordinary case. The cheap half comes first, so a save that does not touch the status
+     * costs no status lookups at all — this runs on every save, and most saves do not touch it.
+     *
+     * A DECLARED transition returns null: `Sales.CloseDeal` and `Sales.ReopenDeal` announce themselves
+     * before saving, and that IS the flow running. Without this term, the operation's own save would
+     * re-enter the flow it is already executing.
+     *
+     * Creation returns null too. A deal born closed has no transition to have run, and the opening
+     * default (`needsStatusDefault`) would otherwise read as one.
+     */
+    private planStatusTransition;
+    /**
+     * Run the close or the reopen that the caller's status write asked for.
+     *
+     * WHY THE OPERATIONS AND NOT A COPY OF THEIR WORK. A close writes a stage event, creates a contract
+     * and two finance tasks for a won B2B deal, and voids the order for a lost one; a reopen undoes the
+     * stamps and returns the order. All of it already exists, is transactional, and is pinned by the
+     * `close-deal` checks. Reimplementing any of it here would be a second copy of the most
+     * consequential code in this app.
+     *
+     * IMPORTED LAZILY because `CloseDealOperation` imports this class, so a top-level import would be a
+     * cycle. The module system caches it, so this costs nothing after the first transition in a process.
+     *
+     * A LOST CLOSE STILL NEEDS ITS LOSS REASON, and a caller who set the status without one gets the
+     * operation's own refusal rather than a second, vaguer one from here. `LossReasonID` and `LossNotes`
+     * are columns on this deal, so an importer that sets them alongside the status has supplied
+     * everything the close needs -- which is the case #205 is about.
+     */
+    private runStatusTransition;
     /**
      * The snapshot an ordinary stage move owes the append-only log, or null when the deal did not move.
      *
@@ -527,14 +559,48 @@ export declare class DealEntityServer extends DealEntity {
     private _declaredTransition;
     private _lastStageEventID;
     private _lockedAtSave;
+    /**
+     * The status the caller asked for, held while the field is reverted to its persisted value so the
+     * close lock can do its real job. `refuseSave` puts it back; see the note there for why.
+     */
+    private _revertedStatusTarget;
     /**
      * The fields that stay editable on a locked deal — read from the SHARED rule, not redeclared.
      *
-     * It moved to `@mj-biz-apps/sales-entities` so the Explorer Deal form can apply the same list. A
-     * second copy here would drift, and the drift would only ever surface as a user typing into a field
-     * the server then refuses. See `close-lock.ts` for the reasoning; CD14 pins it to real behaviour.
+     * It lives in `@mj-biz-apps/sales-entities` so the Explorer Deal form and the workspace apply the
+     * same list. A second copy here would drift, and the drift would only ever surface as a user typing
+     * into a field the server then refuses. See `close-lock.ts`; CD14 pins it to real behaviour.
+     *
+     * A FUNCTION, not a constant, since golive#206's "Loss Notes (Lost deals only)": the answer depends
+     * on the deal's outcome, so the outcome has to reach it. It used to be a flat `ReadonlySet` held in
+     * a static, which is precisely how a caller ends up with the list and without the condition.
      */
-    private static readonly LOCK_EDITABLE_FIELDS;
+    private static lockEditableFields;
+    /**
+     * The child collections that stay editable on a locked deal.
+     *
+     * Named here rather than in `sales-entities` because, unlike the field list, no other surface needs
+     * it yet: the grids decide their own New/delete affordances. If a form ever has to render this, it
+     * moves next to `DEAL_FIELDS_EDITABLE_WHILE_LOCKED` for the same reason that one moved.
+     *
+     * ── WHAT THIS DOES AND DOES NOT CATCH TODAY ─────────────────────────────────────────────────
+     *
+     * The Deal declares exactly TWO child collections (`metadata/entity-relationships`):
+     * `PaymentSchedule` and `Team`. Both are named here, so `dirtyCollections` below is currently
+     * always empty and this check refuses nothing in practice.
+     *
+     * That is deliberate and it is not the same as the check being pointless. It is an ALLOW-LIST, so
+     * a collection added later is refused without anyone remembering to add it — which is the whole
+     * property the previous "freeze every dirty companion" rule existed for. What it means is that
+     * the freeze direction has no companion to demonstrate it on right now, and no check can prove
+     * it until a third collection exists. Said out loud so nobody reads the guard as tested.
+     *
+     * ORDER LINES ARE NOT A COMPANION OF THE DEAL and never were — they belong to the ORDER, in the
+     * Orders app. An earlier version of this comment listed `Lines` alongside these two, which made
+     * this look like the thing freezing them. It is not: that is bizapps-orders#206, which adds a veto
+     * seam Sales registers into.
+     */
+    private static readonly LOCK_EDITABLE_COMPANIONS;
     /**
      * Runs `body` with the close lock suppressed, and always restores it.
      *
@@ -551,19 +617,59 @@ export declare class DealEntityServer extends DealEntity {
      * the current value instead would make a deal impossible to close.
      */
     /**
-     * The refusal for a status write that would lock the deal without closing it.
+     * Refuse this save, and leave the reason where the CALLER reads it.
      *
-     * Null in every ordinary case, including the three that look similar and are not:
+     * ── WHY LOGGING WAS NOT ENOUGH ────────────────────────────────────────────────
      *
-     *   · a DECLARED transition — `Sales.CloseDeal` announced itself, so the close is running;
-     *   · LEAVING a locking status — that is a reopen, and the close lock already refuses a bare one,
-     *     with a message that names `Sales.ReopenDeal`;
-     *   · a status that does not lock — ordinary pipeline movement, which is most saves.
+     * Every refusal in `Save` used to be `LogError(...)` followed by `return false`, so a caller got a
+     * bare `false` and the reason went to the server log. golive#207 row 18 is explicit about what that
+     * message is for: row 17 is what the FORM shows a person, and row 18 is "what the save returns to
+     * whoever asked — the form, an import, an agent or a raw API call". Logged, it returned to nobody.
+     * The form looked fine only because `DealFormComponentExtended.Validate()` produces row 17 for
+     * itself; every other caller got silence.
      *
-     * Creation is excluded too: a deal born closed has no transition to have run, and the opening
-     * default (`needsStatusDefault`) would otherwise be read as one.
+     * `RegisterResultHistoryEntry` is what core uses to record a failed write, and it is what puts the
+     * text on `LatestResult` — registered rather than assigned, because `LatestResult` returns null
+     * when the history is empty while TYPING itself non-null, which is how the same mistake reached
+     * production in orders' line delete.
      */
-    private bareCloseRefusal;
+    private refuseSave;
+    /**
+     * Report a failure that happened AFTER `super.Save()` already registered a SUCCESS result.
+     *
+     * ── WHY THIS IS NOT `refuseSave` ──────────────────────────────────────────────────────────────
+     *
+     * `Save()` returning false was, on these paths, the ONLY signal. `super.Save()` had already
+     * registered a success entry and `this.Load(this.ID)` does not clear the history -- core guards
+     * its `init()` with `if (!this.IsSaved)` and the deal is saved -- so a caller doing the obvious
+     * thing read:
+     *
+     *     await deal.Save()                 -> false
+     *     deal.LatestResult.Success         -> TRUE
+     *     deal.LatestResult.CompleteMessage -> undefined  -> "Unknown error"
+     *
+     * A caller following exactly the pattern `deal-workspace.service.ts` uses was told the save
+     * succeeded. Worse than silent: the last thing on the history contradicted the return value.
+     *
+     * Two things differ from `refuseSave` and both matter:
+     *
+     * 1. IT DOES NOT PUT THE STATUS BACK. `refuseSave` restores the caller's target because nothing
+     *    was written and a retry must still carry it. Here the row has already moved (or been rolled
+     *    back) and `Load()` has resynced this object to it -- re-dirtying a field to a value the
+     *    database just rejected would invite the same failure on the next save.
+     * 2. IT CARRIES THE OPERATION'S ISSUES. `CloseDealOperation` returns a structured `Issues` array
+     *    which was being joined into a `LogError` and dropped. Those sentences are the only thing
+     *    that says WHY the close refused, and they are what the user needs.
+     *
+     * AND WHY NOT A TRANSACTION, since "both or neither" is the obvious wish: the transition reaches
+     * bizapps-contracts and bizapps-orders through seams, so there is no single database to be atomic
+     * in; `CloseDealOperation` is a remote operation that owns its own scope and rollback; and it
+     * loads its own copy of this deal, which is exactly why it must run after the commit rather than
+     * inside it. Atomicity is not available here, so honesty about the partial apply is the fix.
+     * Narrowing the window belongs upstream, in the pre-flight that already refuses a lost close with
+     * no loss reason before a single row moves.
+     */
+    private reportPostSaveFailure;
     private checkCloseLock;
     /**
      * Whether a status carries `LocksDeal`.
@@ -572,6 +678,28 @@ export declare class DealEntityServer extends DealEntity {
      * working. It is also why the lock is a property of the STATUS TYPE rather than of the stage.
      */
     private statusLocksDeal;
+    /**
+     * The two flags the lock needs off a status row: does it lock the deal, and is it a LOSS.
+     *
+     * One read for both, because every caller that wants the second also wants the first, and two
+     * round trips for two columns of one row is a cost with nothing to show for it.
+     *
+     * ── THE TWO FAILURE DEFAULTS POINT THE SAME WAY ─────────────────────────────────────────────
+     *
+     * `LocksDeal` FAILS CLOSED: if the status cannot be read we cannot prove the deal is unlocked, and
+     * wrongly allowing an edit to a closed deal is the more expensive mistake. `IsLost` fails to
+     * `false` for the same reason read the other way round — `false` means Loss Notes is NOT carved
+     * out, so an unreadable status refuses more, never less.
+     *
+     * ── AND THAT IS WHY `Read` IS REPORTED SEPARATELY ──────────────────────────────────────
+     *
+     * "Refuses more, never less" holds for the LOCK and inverts for the TRIGGER. `planStatusTransition`
+     * reads `LocksDeal` to mean "the target status closes the deal", so the same fail-closed default
+     * turns a transient read failure into a REAL CLOSE — stage event, contract, finance tasks, a voided
+     * order — on a save that asked for none of it. One default cannot serve both readings, so callers
+     * are told whether the row was actually read and decide for themselves.
+     */
+    private readStatusLockFlags;
     /**
      * Forces `Deal.CompanyID` to the pipeline's company, ignoring whatever the caller supplied.
      *
@@ -633,6 +761,74 @@ export declare class DealEntityServer extends DealEntity {
      * conditions mirror `stampOwnerFromTeam`'s guard exactly, which is what keeps them from disagreeing.
      */
     private ownerStampEditRefusal;
+    /**
+     * Is the ROSTER driving this save, rather than a caller naming an owner out of thin air?
+     *
+     * Three places need this answer and they must never disagree, which is how a defect got in:
+     * `ownerStampEditRefusal` and `stampOwnerFromTeam` each spelled the condition out, `checkCloseLock`
+     * did not ask at all, and `DealEntity.SetOwner()` — which loads the roster and then assigns the
+     * stamp — was refused on a locked deal for editing a frozen field. golive#206 item 2 says
+     * reassigning a rep after close is record-keeping and must be allowed.
+     *
+     * `Team.Load()` is what makes it true, and `SetOwner` calls it first. A caller who hand-sets
+     * `OwnerEmployeeID` without touching the roster gets `false` here and the refusal it deserves.
+     * A caller who sets BOTH gets no advantage: `stampOwnerFromTeam` re-derives the stamp from the
+     * roster afterwards and overwrites whatever was supplied.
+     */
+    private get RosterDrivesThisSave();
+    /**
+     * Gives a NEW deal an owner: the account's owner when it has one, otherwise whoever is creating it.
+     *
+     * ── WHY THIS EXISTS ─────────────────────────────────────────────────────────────────────────────
+     *
+     * Nothing populated `DealTeamMember`. Not the deal type, not the pipeline, not the account — a deal
+     * was born with an empty roster, `stampOwnerFromTeam()` had nothing to derive from, and the Overview
+     * then reported "No owner assigned." on a deal created seconds earlier. Worse, the form's team panel
+     * is gated on the deal being saved, so at the moment of creation there was no way to supply one
+     * either: every new deal was unowned and stayed that way until somebody noticed.
+     *
+     * ── WHY IT IS HERE AND NOT ON THE FORM ──────────────────────────────────────────────────────────
+     *
+     * `DealTeamMember` is the source of truth for who is on a deal and `Deal.OwnerEmployeeID` is a stamp
+     * derived from it, so a form that wrote either would be the second authority on membership. Putting
+     * it in `Save()` means an Action, an agent and the HubSpot importer all get the same default from
+     * the same code, which is the whole reason the owner rules live on the entity.
+     *
+     * ── THE ORDER OF PREFERENCE, AND WHY ────────────────────────────────────────────────────────────
+     *
+     * The ACCOUNT's owner first. A deal on an existing customer belongs to whoever runs that customer,
+     * and that is true whether a rep, an SE or an admin typed it in — so it beats the creator, who is
+     * merely the person at the keyboard. The creator is the fallback for a deal with no account yet, or
+     * an account nobody owns, where the person entering it is the best answer available.
+     *
+     * ── EVERY WAY THIS DECLINES TO ACT ──────────────────────────────────────────────────────────────
+     *
+     * It is a DEFAULT, not a rule, so each of these leaves the deal exactly as the caller left it:
+     *
+     *  - not a create. An update never needs one; re-deriving on every save would silently re-own a
+     *    deal whose owner had been deliberately removed.
+     *  - the caller already supplied a roster. `RosterDrivesThisSave` is the same guard
+     *    `stampOwnerFromTeam` uses, so an importer or an Action that sets its own team is never
+     *    second-guessed — and the two cannot disagree about what "the caller is managing this" means.
+     *  - nothing resolves. A context user with no linked Employee (`System` and `Anonymous` have none)
+     *    and no account owner leaves the deal unowned, which is exactly what happens today. Refusing the
+     *    save because we could not GUESS an owner would turn a working create into a broken one.
+     *
+     * A failure to READ the account is also not fatal, for the same reason: the deal still saves, just
+     * without a default. The one thing this must never do is cost someone a deal they were creating.
+     */
+    private seedOwnerOnCreate;
+    /** The owner of the account this deal is for, or null when there is no account or no owner. */
+    private accountOwnerEmployeeID;
+    /**
+     * The Employee behind the user doing the creating, or null when they have none.
+     *
+     * READ AS A STRING despite `UserInfo.EmployeeID` being typed `number` in `@memberjunction/core`.
+     * The column is a `uniqueidentifier` — verified against the database, where this user's value is a
+     * GUID — so the declared type is stale. Trusting it would coerce a GUID through a numeric type and
+     * produce `NaN` or a truncated id, which would then be written into a foreign key.
+     */
+    private creatorEmployeeID;
     private stampOwnerFromTeam;
 }
 //# sourceMappingURL=DealEntityServer.d.ts.map

package/dist/DealEntityServer.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"DealEntityServer.d.ts","sourceRoot":"","sources":["../src/DealEntityServer.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4CG;AACH,OAAO,EAGH,iBAAiB,EAIpB,MAAM,sBAAsB,CAAC;AAQ9B,OAAO,EAEH,UAAU,EAIb,MAAM,6BAA6B,CAAC;AA0DrC;;;;;GAKG;AACH;;;;GAIG;AACH,MAAM,MAAM,kBAAkB,GAAG,OAAO,GAAG,QAAQ,CAAC;AAqBpD,qBACa,gBAAiB,SAAQ,UAAU;IAC5C;;;;OAIG;IACH,IAAoB,0BAA0B,IAAI,OAAO,CAExD;IAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA4CG;IACmB,IAAI,CAAC,OAAO,CAAC,EAAE,iBAAiB,GAAG,OAAO,CAAC,OAAO,CAAC;YAyB3D,YAAY;IAmN1B;;;;;;;;;;;;;;;;;;OAkBG;IACH,OAAO,CAAC,cAAc;IAmDtB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA6BG;YACW,eAAe;IAyI7B;;;;;;OAMG;YACW,gBAAgB;IAqD9B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA2CG;IACH,OAAO,CAAC,sBAAsB;IAmC9B;;;;;;;;;;;;;;;;;OAiBG;IACH,OAAO,CAAC,+BAA+B;IAgBvC;;;;;;;;;;;;OAYG;IACH,OAAO,CAAC,QAAQ,CAAC,oBAAoB,CAAgB;IAErD,IAAW,mBAAmB,IAAI,SAAS,MAAM,EAAE,CAElD;IAED;;;;;;;;;;;;;;;OAeG;IACH;;;;;;;;;;;;;;;;;;;;;;;;;;;OA2BG;YACW,iBAAiB;IA2F/B;;;;;;;;;;;;;;;;;;;;;;OAsBG;IACH;;;;;;;;;;;;;;;;;;;;;;;;;OAyBG;IACH,OAAO,CAAC,mBAAmB;IAO3B,OAAO,CAAC,kBAAkB;IAmE1B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAmCG;YACW,sBAAsB;YAoBtB,oBAAoB;IAmDlC;;;;;;;;;;;;;;;;;;;;;;;OAuBG;YACW,qBAAqB;IA2DnC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA8CG;YACW,sBAAsB;IA0HpC;;;;;OAKG;IACH,OAAO,CAAC,iBAAiB,CAAS;IAElC;;;;;;;;;OASG;IACH,OAAO,CAAC,qBAAqB,CAAS;IAEtC;;;;;;;;;;;;OAYG;IACH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAiCG;IACI,iBAAiB,CAAC,IAAI,EAAE,kBAAkB,EAAE,IAAI,EAAE,MAAM,GAAG,IAAI,GAAG,IAAI;IAI7E,sFAAsF;IACtF,IAAW,gBAAgB,IAAI,MAAM,GAAG,IAAI,CAE3C;IAED,OAAO,CAAC,mBAAmB,CAAmC;IAC9D,OAAO,CAAC,iBAAiB,CAAuB;IAChD,OAAO,CAAC,aAAa,CAAS;IAE9B;;;;;;OAMG;IACH,OAAO,CAAC,MAAM,CAAC,QAAQ,CAAC,oBAAoB,CAAqC;IAEjF;;;;;OAKG;IACU,WAAW,CAAC,CAAC,EAAE,IAAI,EAAE,MAAM,OAAO,CAAC,CAAC,CAAC,GAAG,OAAO,CAAC,CAAC,CAAC;IAS/D;;;;;;;OAOG;IACH;;;;;;;;;;;;OAYG;YACW,gBAAgB;YA4BhB,cAAc;IAkD5B;;;;;OAKG;YACW,eAAe;IAuB7B;;;;;;;;;;;;;;OAcG;YACW,wBAAwB;IA8BtC;;;;;;;;;;;;;;;OAeG;IACH;;;;;;;;;;;;;;;;;;;;;;;;;;;OA2BG;IACH,OAAO,CAAC,qBAAqB;YAaf,kBAAkB;CASnC"}
+{"version":3,"file":"DealEntityServer.d.ts","sourceRoot":"","sources":["../src/DealEntityServer.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4CG;AACH,OAAO,EAIH,iBAAiB,EAIpB,MAAM,sBAAsB,CAAC;AAQ9B,OAAO,EAGH,UAAU,EAGb,MAAM,6BAA6B,CAAC;AA4FrC;;;;;GAKG;AACH;;;;GAIG;AACH,MAAM,MAAM,kBAAkB,GAAG,OAAO,GAAG,QAAQ,CAAC;AAqBpD,qBACa,gBAAiB,SAAQ,UAAU;IAC5C;;;;OAIG;IACH,IAAoB,0BAA0B,IAAI,OAAO,CAExD;IAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA4CG;IACmB,IAAI,CAAC,OAAO,CAAC,EAAE,iBAAiB,GAAG,OAAO,CAAC,OAAO,CAAC;YA0B3D,YAAY;IAkU1B;;;;;;;;;;;;OAYG;YACW,oBAAoB;IA6ClC;;;;;;;;;;;;;;;;OAgBG;YACW,mBAAmB;IAgEjC;;;;;;;;;;;;;;;;;;OAkBG;IACH,OAAO,CAAC,cAAc;IAmDtB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA6BG;YACW,eAAe;IA0J7B;;;;;;OAMG;YACW,gBAAgB;IAqD9B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA2CG;IACH,OAAO,CAAC,sBAAsB;IAmC9B;;;;;;;;;;;;;;;;;OAiBG;IACH,OAAO,CAAC,+BAA+B;IAgBvC;;;;;;;;;;;;OAYG;IACH,OAAO,CAAC,QAAQ,CAAC,oBAAoB,CAAgB;IAErD,IAAW,mBAAmB,IAAI,SAAS,MAAM,EAAE,CAElD;IAED;;;;;;;;;;;;;;;OAeG;IACH;;;;;;;;;;;;;;;;;;;;;;;;;;;OA2BG;YACW,iBAAiB;IA2F/B;;;;;;;;;;;;;;;;;;;;;;OAsBG;IACH;;;;;;;;;;;;;;;;;;;;;;;;;OAyBG;IACH,OAAO,CAAC,mBAAmB;IAO3B,OAAO,CAAC,kBAAkB;IAmE1B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAmCG;YACW,sBAAsB;YAoBtB,oBAAoB;IAmDlC;;;;;;;;;;;;;;;;;;;;;;;OAuBG;YACW,qBAAqB;IA2DnC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA8CG;YACW,sBAAsB;IA0HpC;;;;;OAKG;IACH,OAAO,CAAC,iBAAiB,CAAS;IAElC;;;;;;;;;OASG;IACH,OAAO,CAAC,qBAAqB,CAAS;IAEtC;;;;;;;;;;;;OAYG;IACH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAiCG;IACI,iBAAiB,CAAC,IAAI,EAAE,kBAAkB,EAAE,IAAI,EAAE,MAAM,GAAG,IAAI,GAAG,IAAI;IAI7E,sFAAsF;IACtF,IAAW,gBAAgB,IAAI,MAAM,GAAG,IAAI,CAE3C;IAED,OAAO,CAAC,mBAAmB,CAAmC;IAC9D,OAAO,CAAC,iBAAiB,CAAuB;IAChD,OAAO,CAAC,aAAa,CAAS;IAC9B;;;OAGG;IACH,OAAO,CAAC,qBAAqB,CAAuB;IAEpD;;;;;;;;;;OAUG;IACH,OAAO,CAAC,MAAM,CAAC,kBAAkB;IAIjC;;;;;;;;;;;;;;;;;;;;;;;OAuBG;IACH,OAAO,CAAC,MAAM,CAAC,QAAQ,CAAC,wBAAwB,CAG7C;IAEH;;;;;OAKG;IACU,WAAW,CAAC,CAAC,EAAE,IAAI,EAAE,MAAM,OAAO,CAAC,CAAC,CAAC,GAAG,OAAO,CAAC,CAAC,CAAC;IAS/D;;;;;;;OAOG;IACH;;;;;;;;;;;;;;;;OAgBG;IACH,OAAO,CAAC,UAAU;IA6BlB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAkCG;IACH,OAAO,CAAC,qBAAqB;YAmBf,cAAc;IAgH5B;;;;;OAKG;YACW,eAAe;IAI7B;;;;;;;;;;;;;;;;;;;;OAoBG;YACW,mBAAmB;IAyBjC;;;;;;;;;;;;;;OAcG;YACW,wBAAwB;IA8BtC;;;;;;;;;;;;;;;OAeG;IACH;;;;;;;;;;;;;;;;;;;;;;;;;;;OA2BG;IACH,OAAO,CAAC,qBAAqB;IAa7B;;;;;;;;;;;;;OAaG;IACH,OAAO,KAAK,oBAAoB,GAE/B;IAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAwCG;YACW,iBAAiB;IAwC/B,+FAA+F;YACjF,sBAAsB;IAiCpC;;;;;;;OAOG;IACH,OAAO,CAAC,iBAAiB;YAMX,kBAAkB;CASnC"}