charness 0.0.0-stage → 3.0.0

package/dist/utils/compactOnIdle.d.ts

@@ -0,0 +1,329 @@
+/**
+ * @description Pure decision + text helpers for the compact-on-idle feature and
+ * the shared closing-section instruction (plan
+ * `agent/tasks/actual/2026-09-14-self-compact-and-compact-on-idle.md`, F2).
+ *
+ * Kept out of `bot.ts` (which cannot be imported by tests — its module-scope
+ * `parseEnv()` exits without a bot token) so every branch is unit-testable,
+ * mirroring `getCompactCommandRoute` in `compactCommandRoute.ts`.
+ */
+import type { CompactCommandRoute } from './compactCommandRoute';
+/**
+ * Idle interval before an untouched, idle agent session is auto-compacted (F2)
+ * and, on a backend that can be suspended, stopped (lifecycle plan L3). Chosen
+ * to fire just inside the ~1h Anthropic extended prompt-cache window, so the
+ * compaction reads the still-warm cached prefix cheaply and a resume minutes
+ * later still finds the cache. `AGENT_IDLE_MINUTES` overrides it for a test or
+ * live-test instance only (L-D9) — see {@link getAgentIdleMs}.
+ */
+export declare const idleCompactMs: number;
+/**
+ * @description The idle window, honouring the `AGENT_IDLE_MINUTES` override (a
+ * test needs minutes, not an hour; same pattern as `REQUEST_BACKSTOP_MINUTES`).
+ * A missing, non-numeric or non-positive value keeps {@link idleCompactMs}.
+ */
+export declare function getAgentIdleMs(overrideMinutes: string | undefined): number;
+/**
+ * Floor delay for an OVERDUE arm (the thread has been idle longer than
+ * {@link idleCompactMs}, across one or more bot restarts). Never fire instantly at
+ * boot: the reattach is still adopting sessions and the topic may be about to
+ * receive a real prompt, so give it a minute of grace first.
+ */
+export declare const compactIdleOverdueMinDelayMs = 60000;
+/**
+ * Window the overdue arms are SPREAD over, on top of
+ * {@link compactIdleOverdueMinDelayMs}. See {@link getIdleCompactionArmDecision}
+ * for why the spread exists.
+ */
+export declare const compactIdleOverdueSpreadMs: number;
+/**
+ * Which of {@link getIdleCompactionArmDecision}'s three cases produced a delay.
+ * Returned ALONGSIDE the delay rather than re-derived by the caller: the pure
+ * function owns the boundaries, and a diagnostic that recomputes them from the same
+ * inputs would start naming a case the timer is not in the moment one boundary
+ * moves — a log that can lie is worse than no log.
+ */
+export type IdleCompactionArmKind = 'fullWindow' | 'remainder' | 'overdue';
+/** A {@link getIdleCompactionArmDecision} decision: the delay and which case it came from. */
+export interface IdleCompactionArmDecision {
+    delayMs: number;
+    kind: IdleCompactionArmKind;
+}
+/**
+ * @description When the idle watchdog should fire for a thread, given when that
+ * thread was last ACTIVE (persisted, so it survives a restart) — the delay plus
+ * which of the three cases produced it.
+ *
+ * Three cases (reported back as {@link IdleCompactionArmKind}):
+ *  - no persisted history (`lastActivityAt === 0`) — a fresh session, or a state
+ *    file written before the tracking existed ⇒ the full {@link idleCompactMs}
+ *    window, i.e. exactly the pre-persistence behaviour.
+ *  - still inside the window ⇒ the REMAINDER, clamped to at most the full window:
+ *    a backward wall-clock step (an NTP correction on a VPS) puts `lastActivityAt`
+ *    in the FUTURE, which would otherwise make the thread wait the whole window
+ *    PLUS the skew — and a skew over ~24.8 days overflows `setTimeout`, which then
+ *    fires immediately with a `TimeoutOverflowWarning`. "The remainder can never
+ *    exceed the full window" is true by definition and costs nothing to enforce.
+ *    The remainder itself is the restart fix: the bot runs in hot-reload mode and
+ *    restarts on every code change, so re-arming a flat 55 minutes each time meant
+ *    a busy development day never let any topic reach the threshold.
+ *  - already past the window (idle across one or more restarts) ⇒ OVERDUE, so
+ *    fire soon, but staggered: {@link compactIdleOverdueMinDelayMs} plus a
+ *    per-thread offset inside {@link compactIdleOverdueSpreadMs}. The boot
+ *    reattach adopts every live session at once; without the stagger every
+ *    overdue topic would start an LLM compaction turn and post its notice in the
+ *    same instant. Spreading them over ~1–11 minutes keeps the backlog orderly,
+ *    and deriving the offset from the thread key keeps it deterministic (hence
+ *    testable) instead of random.
+ *
+ * The stagger being DETERMINISTIC was considered and chosen, not overlooked: a
+ * thread whose offset lands near the top of the spread never fires while the bot
+ * reloads more often than that offset, and a random offset would eventually get
+ * lucky. It is still the wrong trade — a random offset makes the fire time
+ * unpredictable and untestable, the starvation it would avoid lasts only while the
+ * operator is actively rebuilding (a state that ends), and under reloads that
+ * frequent a FULL-window arm starves just as surely, so the stagger is not
+ * uniquely affected. Do not re-litigate this as an oversight.
+ *
+ * An overdue thread is compacted even though its prompt cache has long gone
+ * cold. The 55-minute interval exists to make the compaction TURN itself cheap
+ * against a warm cache, but the payoff of compacting is that every SUBSEQUENT
+ * turn in that session reads a small context instead of a huge one — clearly
+ * worth one uncached read, whereas skipping it leaves the session permanently
+ * bloated.
+ */
+export declare function getIdleCompactionArmDecision(input: {
+    threadKeyString: string;
+    lastActivityAt: number;
+    now: number;
+    /** The idle window in force ({@link getAgentIdleMs}); the default is {@link idleCompactMs}. */
+    idleWindowMs?: number;
+}): IdleCompactionArmDecision;
+/**
+ * @description Resolve whether compact-on-idle is enabled for a thread. A
+ * per-thread override always wins; otherwise the instance-wide default applies,
+ * which is ON when unset (mirrors `traceAllThreads` — the feature ships enabled).
+ */
+export declare function resolveCompactOnIdleEnabled(globalDefault: boolean | undefined, threadOverride: boolean | undefined): boolean;
+/**
+ * @description Resolve whether the full compaction summary is posted for a thread
+ * (`/compact_summary`). A per-thread override always wins; otherwise the
+ * instance-wide default applies, which is OFF when unset: the operator asked for a
+ * compaction to end in one short line, with the summary there only for a topic
+ * (or an instance) that turns it on.
+ *
+ * Unlike compact-on-idle this is read at COMPACTION time rather than used to arm a
+ * timer, so it is meaningful in a topic with no live session and is deliberately
+ * not gated on one.
+ */
+export declare function resolveCompactSummaryEnabled(globalDefault: boolean | undefined, threadOverride: boolean | undefined): boolean;
+/**
+ * @description Whether the session is busy for a REAL running turn, as opposed
+ * to merely idle-WAITING on an unanswered interactive question. Both states make
+ * `checkIsBusy` report `true`, but D1 draws them apart: a pending question at idle
+ * is a FIRE condition (reject + compact + re-ask), not a reason to hold off, while
+ * a genuinely running turn still blocks the idle compaction. So the fire guard
+ * treats "busy" as `checkIsBusy && !hasPendingQuestion`.
+ */
+export declare function checkIsBusyForRealTurn(input: {
+    isBusy: boolean;
+    hasPendingQuestion: boolean;
+}): boolean;
+/**
+ * @description Whether the process is WORKING at the idle fire (L-D2): a real
+ * running turn ({@link checkIsBusyForRealTurn} — a pending question excuses the
+ * turn, D1) OR background work the question never excuses (a background task,
+ * input not yet taken in, a compaction in flight). The two are read apart so a
+ * question pending over a running background task still reads as working: the
+ * D1 reject-compact-re-ask would otherwise end in a stop that kills the task.
+ */
+export declare function checkIsWorkingAtIdle(input: {
+    isBusy: boolean;
+    hasPendingQuestion: boolean;
+    hasBackgroundWork: boolean;
+}): boolean;
+/** What the idle timer does when it fires: the compaction half and the stop half, each with its reasons. */
+export interface IdleFireDecision {
+    /** Run the idle compaction (D1/D2). */
+    shouldCompact: boolean;
+    /** Why the compaction is skipped — logged, since a silent skip was the feature's blind spot. */
+    compactionSkipReasons: string[];
+    /** Stop the process afterwards, the session kept resumable (L-D1). */
+    shouldSuspend: boolean;
+    /** Why the process stays. */
+    suspendSkipReasons: string[];
+}
+/**
+ * @description The idle-fire decision, taken the moment the idle timer fires
+ * (lifecycle plan L3). Nothing happens to a session that is not there or is
+ * WORKING (L-D2: a real running turn, a background task, input not yet taken in,
+ * a compaction in flight — a pending interactive question is NOT work, see
+ * {@link checkIsBusyForRealTurn}; D1); the next activity re-arms the timer.
+ *
+ * The compaction runs only when the feature is enabled for the thread, the
+ * per-thread user-latch is NOT already spent (D2 — after a fire it stays latched
+ * until the next genuine USER message re-arms it, so idle compaction runs at most
+ * once per user-active period), at least one agent turn has completed since the
+ * last compaction (otherwise there is nothing new to compress), and no
+ * usage-limit wait is armed (L-D6: a compaction turn would hit the limit).
+ *
+ * The STOP happens whether or not the compaction runs (L-D1: a resume restores
+ * the full history, so a stopped process loses nothing) — on a backend that can
+ * be suspended; the tmux TUI and OpenCode stay (L-D8).
+ */
+export declare function getIdleFireDecision(input: {
+    isSessionActive: boolean;
+    isWorking: boolean;
+    isEnabled: boolean;
+    isLatched: boolean;
+    hasCompletedTurnSinceCompaction: boolean;
+    isLimitWaitArmed: boolean;
+    canSuspend: boolean;
+}): IdleFireDecision;
+/**
+ * @description The maximally-complete-summary guidance (D3) — one canonical text
+ * used on EVERY bot-issued compaction, kept BACKEND-CONSISTENT: it is baked into
+ * the OpenCode fork's compaction prompt (so it also reaches the auto/overflow
+ * compaction the bot can't touch) and, for the Claude backends (which have no
+ * prompt the bot controls), appended to the `/compact <instruction>` the bot
+ * sends. A code constant (not an i18n key) because it is identical across all
+ * locales — it dictates WHAT the summary must contain, never its language — and
+ * because it must mirror the fork's baked wording without 12-locale drift.
+ */
+export declare const compactionSummaryGuidance = "Make the summary MAXIMALLY COMPLETE: preserve every detail needed to continue the work from a clean session with no memory of this conversation \u2014 never drop load-bearing information (decisions, constraints, file paths, commands, error strings, identifiers, active tasks, delegated-work state) for brevity. Capture only SESSION-SPECIFIC working nuances: the user's in-session directives and any deviations from the standard process. Do NOT restate the standard instructions that auto-load at session start (for example CLAUDE.md / AGENTS.md / rules files) \u2014 they reload automatically on the fresh session, so duplicating them only wastes the summary. Keep the conversational directives, active exceptions, and delegated-work state; drop the static rulebook.";
+/**
+ * @description The loaded-skills guidance, on EVERY compaction of both backends:
+ * bot-issued ones carry it in their instruction, and each backend's own overflow
+ * compaction gets it from a bot-installed hook — Claude's `PreCompact` hook
+ * (`claudeCompactHook.ts`, which also matches on this exact text to skip a
+ * compaction that already carries it) and OpenCode's compaction plugin
+ * (`openCodeCompactPlugin.ts`). A skill is loaded on demand mid-session (a tool call whose
+ * result carries its instructions), so — unlike CLAUDE.md / AGENTS.md — nothing
+ * reloads it after a compaction: the summary drops its text and the fresh
+ * session keeps working without the procedure it was following. Naming the
+ * skills and saying in plain words that they must be loaded again is the only
+ * way the continuing session learns to re-invoke them.
+ */
+export declare const compactionSkillsGuidance = "List every skill that was loaded (invoked) during this session by its exact name, and state explicitly, in plain words, that the continuing session MUST load each of these skills again and follow it before resuming the work: a skill's instructions are not carried over by this summary, so without reloading them the fresh session works without them. If no skill was loaded, omit this.";
+/**
+ * @description Compose the per-invocation compaction instruction the bot passes
+ * to a backend (D3 + loaded skills + F2 closing section). The general summary
+ * guidance is appended ONLY when the backend does NOT already bake it into its
+ * own prompt — OpenCode bakes it in the fork (`bakesSummaryGuidance: true`) so
+ * re-sending it would duplicate the text, whereas the Claude backends have no
+ * bot-controlled prompt and must receive it every time. The skills guidance is
+ * skipped the same way when the backend's own compaction prompt already gets it
+ * (`bakesSkillsGuidance`: an OpenCode server running the bot's compaction plugin,
+ * which cannot see this instruction and so cannot skip a duplicate itself). The F2 closing-section directive
+ * (per-locale, may carry a language directive) is appended LAST when present,
+ * because it tells the model to write nothing after its end marker.
+ */
+export declare function buildCompactionInstruction(input: {
+    bakesSummaryGuidance: boolean;
+    summaryGuidance: string;
+    bakesSkillsGuidance: boolean;
+    skillsGuidance: string;
+    closingSectionInstruction?: string;
+}): string | undefined;
+/**
+ * @description Render a context-token count for the compaction completion
+ * message ("314 150 → 12 883 tokens"): digits grouped in threes.
+ *
+ * Deliberately NOT `Number.toLocaleString()` — that formats for the HOST's
+ * locale, not the topic's, so the same count would render differently depending
+ * on the machine the bot happens to run on. This is fixed and testable instead.
+ */
+export declare function formatTokenCount(count: number): string;
+/**
+ * FIXED (English, locale-independent) sentinel markers the closing section is
+ * wrapped in. Sentinels — not a markdown heading — because the two backends
+ * generate very different summary formats (OpenCode's `## Goals/…` template vs
+ * Claude Code's freeform numbered recap), so a heading match is unreliable while
+ * exact markers are backend-agnostic. They are stripped before a summary is
+ * posted ({@link stripCompactionClosingMarkers}). The per-locale instruction pins
+ * these exact strings, so changing them means changing the instruction wording in
+ * lockstep.
+ */
+export declare const compactionClosingStartMarker = "<<<WHERE_WE_STOPPED>>>";
+export declare const compactionClosingEndMarker = "<<<END_WHERE_WE_STOPPED>>>";
+/**
+ * @description Remove the sentinel marker LINES from a summary that is about to be
+ * posted to the topic, keeping every line of prose — including the closing section
+ * the markers wrap, which is genuine content.
+ *
+ * The markers are machine scaffolding and mean nothing to a reader. A marker sitting ALONE on its
+ * line takes the whole line with it (its own newline included), so the summary is
+ * not left with a blank gap where it stood; a marker the model happened to put
+ * AHEAD of real prose on one line loses only the marker, never the prose. A summary
+ * with no markers comes back unchanged apart from trimming.
+ */
+export declare function stripCompactionClosingMarkers(summaryText: string): string;
+/**
+ * @description Should the bot post the FULL compaction summary into the topic?
+ *
+ * Three independent reasons not to, kept in one testable rule rather than spread
+ * across the call sites:
+ *  - the per-topic `/compact_summary` setting is off;
+ *  - the backend STREAMS its own summary into the topic already
+ *    (`streamsCompactionSummary` — OpenCode's `summarize` produces a real
+ *    assistant message), so the bot posting one too would duplicate it;
+ *  - the route is not a real, awaited compaction: `forwardToAgent` hands
+ *    `/compact` to a TUI that renders its own result and gives the bot no
+ *    completion signal, and `notSupported` never compacts at all — in both cases
+ *    there is no summary of ours to post.
+ */
+export declare function checkShouldPostCompactionSummary(input: {
+    isEnabled: boolean;
+    streamsOwnSummary: boolean;
+    route: CompactCommandRoute;
+}): boolean;
+/**
+ * @description Should the bot announce that a compaction is STARTING (the notice
+ * that goes out BEFORE the wait, for the triggers the operator is present for)?
+ *
+ * Two reasons not to:
+ *  - the route is not one the bot awaits: `forwardToAgent` hands `/compact` to a TUI
+ *    that renders its own progress, and `notSupported` never compacts at all;
+ *  - no session is live. The compaction seam's first guard is exactly that, so
+ *    announcing here would be a promise the very next message retracts — `/compact`
+ *    in a bound topic whose agent was never started hits precisely that, and before
+ *    the notice moved ahead of the wait the operator only ever saw the refusal.
+ *
+ * Deliberately NOT the same rule as the COMPLETION report, which needs no liveness
+ * input: it is reached only after a compaction really succeeded.
+ */
+export declare function checkShouldAnnounceCompactionStart(input: {
+    route: CompactCommandRoute;
+    isSessionActive: boolean;
+}): boolean;
+/** The three parts of an idle-compaction report, each its OWN topic message. */
+export interface IdleCompactionNoticeParts {
+    /** The short idle notice. */
+    notice: string | null;
+    /** The full summary, posted as its own message(s). */
+    summary: string | null;
+    /** The re-asked pending question — always LAST, so its buttons stay reachable. */
+    question: string | null;
+}
+/**
+ * @description Compose an idle-compaction report as SEPARATE parts in the §1.4
+ * order: notice → summary → re-asked question.
+ *
+ * Splitting what used to be one joined message is the point: the re-asked
+ * question carries inline option buttons, and gluing it behind a full summary
+ * would bury those buttons under a wall of text (and the summary alone can
+ * outgrow a single Telegram message).
+ *
+ * The notice is the one short line on its own. It used to carry the summary's
+ * "Where we stopped" block whenever the full summary was off, which still made
+ * every idle compaction a paragraph; with the summary off the operator now gets
+ * the line alone, and the block reaches the topic only inside the full summary.
+ */
+export declare function buildIdleCompactionNoticeParts(input: {
+    /** The idle notice text, or `null` when the compaction FAILED (nothing to announce). */
+    noticeText: string | null;
+    summary: string | null;
+    /** The re-asked question's rendered text, or `null` when none was pending. */
+    questionText: string | null;
+}): IdleCompactionNoticeParts;
+//# sourceMappingURL=compactOnIdle.d.ts.map

package/dist/utils/compactOnIdle.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"compactOnIdle.d.ts","sourceRoot":"","sources":["../../src/utils/compactOnIdle.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,OAAO,KAAK,EAAE,mBAAmB,EAAE,MAAM,uBAAuB,CAAC;AAIjE;;;;;;;GAOG;AACH,eAAO,MAAM,aAAa,QAAiB,CAAC;AAE5C;;;;GAIG;AACH,wBAAgB,cAAc,CAAC,eAAe,EAAE,MAAM,GAAG,SAAS,GAAG,MAAM,CAE1E;AAED;;;;;GAKG;AACH,eAAO,MAAM,4BAA4B,QAAS,CAAC;AAEnD;;;;GAIG;AACH,eAAO,MAAM,0BAA0B,QAAiB,CAAC;AAoBzD;;;;;;GAMG;AACH,MAAM,MAAM,qBAAqB,GAAG,YAAY,GAAG,WAAW,GAAG,SAAS,CAAC;AAE3E,8FAA8F;AAC9F,MAAM,WAAW,yBAAyB;IACxC,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,qBAAqB,CAAC;CAC7B;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA0CG;AACH,wBAAgB,4BAA4B,CAAC,KAAK,EAAE;IAClD,eAAe,EAAE,MAAM,CAAC;IACxB,cAAc,EAAE,MAAM,CAAC;IACvB,GAAG,EAAE,MAAM,CAAC;IACZ,+FAA+F;IAC/F,YAAY,CAAC,EAAE,MAAM,CAAC;CACvB,GAAG,yBAAyB,CAW5B;AAED;;;;GAIG;AACH,wBAAgB,2BAA2B,CACzC,aAAa,EAAE,OAAO,GAAG,SAAS,EAClC,cAAc,EAAE,OAAO,GAAG,SAAS,GAClC,OAAO,CAET;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,4BAA4B,CAC1C,aAAa,EAAE,OAAO,GAAG,SAAS,EAClC,cAAc,EAAE,OAAO,GAAG,SAAS,GAClC,OAAO,CAET;AAED;;;;;;;GAOG;AACH,wBAAgB,sBAAsB,CAAC,KAAK,EAAE;IAC5C,MAAM,EAAE,OAAO,CAAC;IAChB,kBAAkB,EAAE,OAAO,CAAC;CAC7B,GAAG,OAAO,CAEV;AAED;;;;;;;GAOG;AACH,wBAAgB,oBAAoB,CAAC,KAAK,EAAE;IAC1C,MAAM,EAAE,OAAO,CAAC;IAChB,kBAAkB,EAAE,OAAO,CAAC;IAC5B,iBAAiB,EAAE,OAAO,CAAC;CAC5B,GAAG,OAAO,CAEV;AAED,4GAA4G;AAC5G,MAAM,WAAW,gBAAgB;IAC/B,uCAAuC;IACvC,aAAa,EAAE,OAAO,CAAC;IACvB,gGAAgG;IAChG,qBAAqB,EAAE,MAAM,EAAE,CAAC;IAChC,sEAAsE;IACtE,aAAa,EAAE,OAAO,CAAC;IACvB,6BAA6B;IAC7B,kBAAkB,EAAE,MAAM,EAAE,CAAC;CAC9B;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,mBAAmB,CAAC,KAAK,EAAE;IACzC,eAAe,EAAE,OAAO,CAAC;IACzB,SAAS,EAAE,OAAO,CAAC;IACnB,SAAS,EAAE,OAAO,CAAC;IACnB,SAAS,EAAE,OAAO,CAAC;IACnB,+BAA+B,EAAE,OAAO,CAAC;IACzC,gBAAgB,EAAE,OAAO,CAAC;IAC1B,UAAU,EAAE,OAAO,CAAC;CACrB,GAAG,gBAAgB,CAoBnB;AAED;;;;;;;;;GASG;AACH,eAAO,MAAM,yBAAyB,mwBACmtB,CAAC;AAE1vB;;;;;;;;;;;;GAYG;AACH,eAAO,MAAM,wBAAwB,qYACgW,CAAC;AAEtY;;;;;;;;;;;;GAYG;AACH,wBAAgB,0BAA0B,CAAC,KAAK,EAAE;IAChD,oBAAoB,EAAE,OAAO,CAAC;IAC9B,eAAe,EAAE,MAAM,CAAC;IACxB,mBAAmB,EAAE,OAAO,CAAC;IAC7B,cAAc,EAAE,MAAM,CAAC;IACvB,yBAAyB,CAAC,EAAE,MAAM,CAAC;CACpC,GAAG,MAAM,GAAG,SAAS,CAQrB;AAWD;;;;;;;GAOG;AACH,wBAAgB,gBAAgB,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAMtD;AAED;;;;;;;;;GASG;AACH,eAAO,MAAM,4BAA4B,2BAA2B,CAAC;AACrE,eAAO,MAAM,0BAA0B,+BAA+B,CAAC;AAEvE;;;;;;;;;;GAUG;AACH,wBAAgB,6BAA6B,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CAMzE;AAOD;;;;;;;;;;;;;GAaG;AACH,wBAAgB,gCAAgC,CAAC,KAAK,EAAE;IACtD,SAAS,EAAE,OAAO,CAAC;IACnB,iBAAiB,EAAE,OAAO,CAAC;IAC3B,KAAK,EAAE,mBAAmB,CAAC;CAC5B,GAAG,OAAO,CAIV;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,kCAAkC,CAAC,KAAK,EAAE;IACxD,KAAK,EAAE,mBAAmB,CAAC;IAC3B,eAAe,EAAE,OAAO,CAAC;CAC1B,GAAG,OAAO,CAEV;AAED,gFAAgF;AAChF,MAAM,WAAW,yBAAyB;IACxC,6BAA6B;IAC7B,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC;IACtB,sDAAsD;IACtD,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,kFAAkF;IAClF,QAAQ,EAAE,MAAM,GAAG,IAAI,CAAC;CACzB;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,8BAA8B,CAAC,KAAK,EAAE;IACpD,wFAAwF;IACxF,UAAU,EAAE,MAAM,GAAG,IAAI,CAAC;IAC1B,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;IACvB,8EAA8E;IAC9E,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;CAC7B,GAAG,yBAAyB,CAM5B"}