happy2 0.0.11 → 0.0.13

package/README.md

@@ -49,6 +49,16 @@ Open [http://127.0.0.1:3000](http://127.0.0.1:3000) in your browser. Happy (2)
 stores its database, files, generated secrets, agent workspaces, and private Rig
 runtime under `.happy2` in the directory where you start it.
 
+Run it in the background without installing an operating-system service with:
+
+```sh
+npx happy2 daemon start
+npx happy2 daemon stop
+```
+
+The daemon stores `happy2.pid` and `happy2.log` under `./.happy2`. Stopping it
+terminates the daemon process tree and removes the PID file.
+
 Keep Happy (2) running across reboots with:
 
 ```sh

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "happy2",
-  "version": "0.0.11",
+  "version": "0.0.13",
   "description": "Happy (2) desktop web app and server bundle",
   "repository": {
     "type": "git",
@@ -71,7 +71,7 @@
     "@libsql/client": "^0.17.4",
     "@modelcontextprotocol/sdk": "^1.29.0",
     "@paralleldrive/cuid2": "^3.3.0",
-    "@slopus/rig": "^0.0.24",
+    "@slopus/rig": "^0.0.25",
     "drizzle-orm": "^0.45.2",
     "fastify": "^5.8.2",
     "jose": "^6.1.3",

package/packages/happy2-server/PLUGINS.md

@@ -1,34 +1,41 @@
 # Server plugins
 
-Happy (2) plugins package Agent Skills, an MCP server, or both. This first
-server-side implementation installs only packages bundled with the server. It
-already keeps catalog discovery, durable system plugins, immutable package/image
-snapshots, and independent runtime installations separate so a later remote
-catalog/download step can reuse the same boundaries.
+Happy (2) plugins package Agent Skills, a persistent container command, an MCP
+server, or any useful combination of those pieces. Administrators can install a
+built-in package, upload one ZIP, download one ZIP over HTTPS, or import a GitHub
+repository. Catalog discovery, verified preparation, durable system plugins,
+immutable package/image snapshots, writable installation data, and independent
+runtime installations remain separate boundaries.
 
 Plugin management is system-wide and administrator-only. The first installation
 of a catalog package creates one durable system-plugin record and one immutable
 package snapshot; later installations reuse that plugin identity and snapshot.
 Every installation has its own CUID2, variables, selected image, lifecycle, and
-dedicated container when it is a local stdio MCP. Remote MCP configuration is
+dedicated container when it has a local runtime. Remote MCP configuration is
 persisted and health-checked independently per installation. Ready MCP
-installations expose their tools to Rig as durable external functions on every
-agent submission. Happy executes each durable call against the originating
+installations expose their durably cached tools to Rig as external functions on
+every agent submission. Happy executes each durable call against the originating
 installation and resolves the result back into the paused Rig run. This feature
-does not yet inject installed skills, and it does not yet implement upgrade,
-uninstall, marketplace download, or OAuth flows.
-
-Tool discovery is bounded to 15 seconds per agent submission, and one MCP tool
-execution is bounded to 30 seconds so a stalled plugin cannot indefinitely block
-turn submission or Rig's global event consumer. Before execution, Happy claims a
-45-second database lease keyed by Rig session and call ID. Other server instances
-wait for that lease or replay its completed result instead of concurrently
-invoking the same tool. The first terminal outcome, including an MCP error or
-timeout, is persisted and reused for every later event delivery; Happy does not
-automatically retry an ambiguous failure because the first request may already
-have produced an external side effect. A process crash after the MCP side effect
-but before the outcome is committed can still cause one lease-expiry replay, so
-plugin tools with external side effects should themselves be idempotent.
+does not yet inject installed skills or implement in-place upgrade, marketplace
+discovery, or OAuth flows. Remote update checks report drift but deliberately do
+not replace the installed snapshot.
+
+MCP tools are discovered during each runtime activation and atomically replace
+that installation's SQLite cache before it becomes ready. Local discovery runs
+after every container creation, and remote discovery runs on every server
+restart. Rig function discovery reads only this cache rather than opening every
+MCP server again per submission. Each discovery page is bounded to 15
+seconds, and one MCP tool execution is bounded to 30 seconds so a stalled plugin
+cannot indefinitely block turn submission or Rig's global event consumer. Before
+execution, Happy claims a 45-second database lease keyed by Rig session and call
+ID. Other server instances wait for that lease or replay its completed result
+instead of concurrently invoking the same tool. The first terminal outcome,
+including an MCP error or timeout, is persisted and reused for every later event
+delivery; Happy does not automatically retry an ambiguous failure because the
+first request may already have produced an external side effect. A process crash
+after the MCP side effect but before the outcome is committed can still cause one
+lease-expiry replay, so plugin tools with external side effects should themselves
+be idempotent.
 
 Rig sessions use Full access so durable external functions are executable without
 an unresolved permission prompt. Agent code still runs inside Happy's dedicated,
@@ -38,12 +45,16 @@ to a ready installation.
 
 ## Package anatomy
 
-Each built-in package is a directory below `packages/happy2-server/plugins`:
+Each package has this shape. Built-ins live below
+`packages/happy2-server/plugins`; installed snapshots live below the configured
+`plugins.directory`:
 
 ```text
 example-plugin/
 ├── plugin.json
 ├── plugin.png
+├── data/                     # server-owned; absent from source ZIPs
+│   └── <installation-id>/      # persistent writable workspace
 ├── container/                 # optional; used by bundled stdio runtimes
 │   └── Dockerfile
 └── skills/                    # optional
@@ -69,6 +80,16 @@ symlinks, unsafe relative paths, duplicate names, oversized packages, malformed
 frontmatter, and unexpected manifest fields before the catalog becomes
 available.
 
+Uploaded and downloaded ZIPs are capped at 50 MiB compressed. Extraction also
+bounds entry count, file count, individual and total uncompressed sizes, and
+actual DEFLATE output. It rejects ZIP64, encryption, unsupported compression,
+links, path traversal, duplicate paths, local/central filename disagreement,
+invalid checksums, and ambiguous generic archives. A generic uploaded or remote
+ZIP must contain exactly one `plugin.json`. GitHub archives may instead contain
+one root `plugin.json` or multiple `plugins/<name>/plugin.json` packages; when
+there are multiple packages, preparation returns each verified candidate so the
+administrator can choose one.
+
 `plugin.json` uses schema version 1:
 
 ```json
@@ -91,7 +112,13 @@ available.
             "description": "Region used for project queries.",
             "kind": "text"
         }
-    ]
+    ],
+    "container": {
+        "dockerfile": "container/Dockerfile",
+        "command": "/plugin/bin/indexer",
+        "args": ["--watch"],
+        "permissions": ["plugins:list"]
+    }
 }
 ```
 
@@ -101,10 +128,18 @@ The durable system plugin and every installation receive separate CUID2 IDs.
 Variable keys are environment variable names. Every declared variable is
 required for each installation. Secret values are encrypted with AES-256-GCM
 and are never returned by catalog or installation reads; text values are stored
-as ordinary configuration. Both kinds are supplied to a stdio process as
-environment variables.
+as ordinary configuration. Both kinds are supplied to configured local
+processes as environment variables.
 
-A package must contain at least one skill or an `mcp` definition.
+A package must contain at least one skill, `container`, or `mcp` definition.
+`container.command` is optional when the same container exposes a stdio MCP;
+otherwise it is required. A command and stdio MCP run alongside each other in
+the same dedicated installation container. Container variables are supplied to
+each configured process, not persisted in the image or container definition.
+
+`container.permissions` is an exact allowlist of host API capabilities. The
+currently supported permission is `plugins:list`. Unknown and duplicate
+permissions are rejected when the package is loaded.
 
 The bundled `hello` package is the minimal skill-plus-MCP example. It declares no
 variables or MCP authentication, so an administrator can install it with an
@@ -118,10 +153,12 @@ container.
     "mcp": {
         "type": "stdio",
         "command": "/plugin/bin/project-mcp",
-        "args": ["--stdio"],
-        "container": {
-            "dockerfile": "container/Dockerfile"
-        }
+        "args": ["--stdio"]
+    },
+    "container": {
+        "dockerfile": "container/Dockerfile",
+        "args": [],
+        "permissions": []
     }
 }
 ```
@@ -129,7 +166,8 @@ container.
 The Dockerfile path is package-relative. Creating the durable system plugin
 copies the entire package once to `plugins.directory` before writing its
 database record. Each installation lifecycle builds or resolves that exact
-snapshot with the selected local Docker or Podman provider, using a
+snapshot, excluding the server-owned `data/` subtree from the build context,
+with the selected local Docker or Podman provider, using a
 content-addressed `happy2-plugin:<sha256>` tag. It then creates a dedicated,
 read-only container named from the installation CUID2, with `init`, all Linux capabilities
 dropped, privilege escalation disabled, bounded shared memory, and ephemeral
@@ -142,26 +180,38 @@ bundled Dockerfile is responsible for copying or installing its MCP executable
 and dependencies into the image. The MCP command itself must use newline-
 delimited JSON-RPC on stdin/stdout and must not write non-protocol output to
 stdout.
-The fixed `HOME`, `TMPDIR`, and working directory are `/tmp`, so tools that
-need a cache can still run without making the image root writable.
+The fixed `HOME` and `TMPDIR` are `/tmp`. The server creates
+`<plugins.directory>/<plugin-id>/data/<installation-id>` with private
+permissions, bind-mounts it read-write at `/workspace`, and uses `/workspace` as
+the container working directory. This is the plugin's persistent filesystem;
+the image root remains read-only. Different installations never share a data
+directory. Uninstalling the system plugin removes every linked installation,
+container, immutable package asset, and data subtree.
 
 Each installation container stays alive as that installation's plugin runtime.
-Each HTTP MCP session starts
+The optional persistent command is started detached once for each container
+incarnation and monitored through a PID marker in the container's ephemeral
+`/run`. Server restart recovery adopts and resumes monitoring that same command
+without double-starting it. Each HTTP MCP session starts
 the configured command with `docker exec`/`podman exec`; variables reach that
 process through Docker/Podman's environment-copy option. Values are never placed
 in command arguments, Happy's process environment, the long-lived container
 definition, or the image build; they exist only in the short-lived OCI CLI child
-and the MCP process. Variables that could alter the OCI client itself, such as
+and the target persistent-command or MCP process. Variables that could alter the OCI client itself, such as
 `DOCKER_*`, proxy, loader, or executable-path settings, are rejected. Happy
 transparently bridges newline-delimited stdio JSON-RPC to MCP Streamable HTTP, so
 the plugin itself does not need an HTTP server.
 
 ## Stdio MCP using a selected container image
 
-Omit `mcp.container` when the plugin does not bundle its own Dockerfile:
+Omit `container.dockerfile` when the plugin does not bundle its own Dockerfile:
 
 ```json
 {
+    "container": {
+        "args": [],
+        "permissions": []
+    },
     "mcp": {
         "type": "stdio",
         "command": "npx",
@@ -203,6 +253,39 @@ custom static headers described above. Production remote requests are capped at
 1,000,000 bytes and responses at 256,000 bytes, matching the bounded webhook
 transport used for SSRF-safe address pinning.
 
+## External package preparation
+
+External installation is a two-step, administrator-only flow. Preparation does
+all network and archive work before durable installation, and streams progress
+as SSE:
+
+- `POST /v0/admin/pluginPackages/preparePlugin` accepts either multipart form
+  data with one `plugin` ZIP file, or JSON containing
+  `{"source":{"kind":"zip_url"|"github","url":"https://..."}}`.
+- The server downloads remote archives through its public-HTTPS SSRF policy,
+  revalidates and pins DNS at every redirect, verifies package structure and
+  metadata, and emits `progress` events.
+- It emits `prepared` for one candidate or `selection_required` for multiple
+  GitHub candidates. Each candidate includes a 15-minute, administrator-bound,
+  one-use `preparedToken`, the immutable digest, source identity, version,
+  display name, description, skill descriptions, variable definitions, MCP
+  mode, and image metadata.
+- `POST /v0/admin/pluginPackages/installPlugin` accepts the selected
+  `preparedToken`, `variables`, and optional `containerImageId`. It returns HTTP
+  202 after consuming the token and making the installation durable.
+
+A GitHub URL may identify a repository or one `tree/<ref>` URL. The root
+`plugin.json` wins when present; otherwise the server discovers direct
+`plugins/<name>` children. ZIP URLs are stored as their normalized URL. Uploaded
+packages have content-addressed source identities and cannot be checked for a
+remote update.
+
+`POST /v0/admin/systemPlugins/:pluginId/checkForUpdate` is also an SSE endpoint.
+It downloads and verifies the same selected remote path, emits progress, then a
+`checked` event containing installed and remote versions/digests plus
+`updateAvailable`. Built-ins are compared with the current catalog. The check is
+read-only; a changed package requires an explicit future upgrade flow.
+
 ## Installation and lifecycle
 
 `POST /v0/admin/plugins/:shortName/installPlugin` accepts:
@@ -220,8 +303,8 @@ transport used for SSRF-safe address pinning.
 The request body may be omitted when the manifest declares no variables and
 does not require a selected container image.
 
-`containerImageId` is required only for stdio manifests without a bundled
-container, and it is rejected in every other case. Unknown, missing, empty, or
+`containerImageId` is required for every local container manifest without a
+bundled Dockerfile, and it is rejected in every other case. Unknown, missing, empty, or
 oversized variable values are rejected. The endpoint returns HTTP 202 after the
 durable system plugin (created once), immutable package/image snapshot, new
 installation, variables, audit entry, initial state, and sync event are durable.
@@ -235,14 +318,21 @@ explicit upgrade action exists. Catalog reads therefore project the stored
 variable and MCP requirements for the install form while retaining the newer
 catalog version and `updateAvailable` indicator.
 
+`POST /v0/admin/systemPlugins/:pluginId/uninstallPlugin` atomically removes the
+system plugin, all linked installations and secrets, and publishes audit/sync
+evidence. Runtime cleanup then stops linked containers and removes the entire
+stored package directory, including images, descriptors, skills, and every
+installation's persistent `data` directory.
+
 An installation has one of these durable health states:
 
 - `preparing`: copying/reconciling package and image/container state.
 - `starting`: the container exists or remote endpoint is selected and MCP
   initialization/health checking is in progress.
-- `ready`: the MCP server completed initialization and ping (local), or returned
-  a valid initialization response (remote). A skills-only plugin becomes ready
-  immediately after its durable install.
+- `ready`: a container-only command survived its startup probe; or a local or
+  remote MCP server completed initialization, ping, and durable tool discovery.
+  A skills-only plugin becomes ready immediately
+  after its durable install.
 - `broken_configuration`: stored variables, selected image state, manifest
   material, or resolved headers cannot form a valid runtime configuration.
 - `failed`: package integrity, image build, container creation, process startup,
@@ -253,8 +343,10 @@ Every transition updates `plugin_installations`, appends a `plugin.*` sync
 event, and publishes the normal server SSE hint with the `plugins` area. Clients
 must reconcile the durable catalog after a hint; the event itself is not state.
 On server restart, every installation is reconciled again. Its package path and
-SHA-256 digest are revalidated first; local containers are then recreated from
-the installed snapshot, and remote endpoints are rechecked.
+SHA-256 digest are revalidated first; a running local container with matching
+installation and incarnation labels is adopted, otherwise it is recreated from
+the installed snapshot. Adopted persistent commands resume liveness monitoring.
+Remote endpoints are rechecked.
 
 ## Read and MCP endpoints
 
@@ -277,6 +369,72 @@ the installed snapshot, and remote endpoints are rechecked.
   Streamable HTTP bridge for one ready local stdio installation. It follows MCP
   session semantics via `Mcp-Session-Id`. Happy’s existing bearer session is
   required; there is no plugin-specific OAuth exchange.
+- `GET /v0/admin/pluginInstallations/:installationId/mcpTools` returns the last
+  successfully synchronized MCP tool schemas from SQLite. It never contacts the
+  MCP server. Tool discovery is replaced atomically on every runtime activation,
+  including each server restart.
+- `GET /plugins` on the dedicated plugin host listener is the first
+  capability-scoped host API. It is deliberately absent from the product API
+  listener. A
+  container may call it only when its manifest grants `plugins:list` and it
+  presents the incarnation token supplied as `HAPPY2_PLUGIN_API_TOKEN`.
+- `POST /chats/updateChat` on that same listener changes the current chat's
+  `title` and/or `description`. It requires the installation runtime bearer
+  token, the `chats:update` manifest permission, and the current call's chat
+  capability in `X-Happy2-Chat-Token`. The endpoint deliberately accepts no
+  chat ID: the signed capability selects the chat, so tool arguments cannot
+  redirect the update to another conversation.
+
+Container processes receive `HAPPY2_PLUGIN_API_URL` and
+`HAPPY2_PLUGIN_API_TOKEN`. The URL is always
+`http://happy2.host.internal:<plugins.host_api_port>`; the hardened container
+adds `happy2.host.internal:host-gateway`, while the capability-only listener
+binds `plugins.host_api_host` on that fixed port. HTTP/TCP and the OCI
+`host-gateway` mapping work across Docker and Podman on macOS and Linux.
+The cross-platform default bind is `0.0.0.0` because a loopback bind is not
+reachable through Docker Desktop's or Podman's host gateway. Operators who
+expose the host to an untrusted LAN should firewall
+`plugins.host_api_port`; it is a container capability endpoint, not a public
+service.
+
+The token is an RS256 capability containing the installation ID, a random CUID2
+container-incarnation ID, and the exact manifest permissions. Token bytes are
+never stored. The incarnation ID is stored in `plugin_installations` and also
+attached to the OCI container as `dev.happy2.plugin-instance`. On each request,
+Happy verifies the signature, matches the incarnation against the ready database
+row, and confirms that the correspondingly labelled container is running. A
+stopped, missing, or replaced container therefore receives 403. A surviving
+container and its token remain valid after a server restart; startup adopts the
+matching container and refreshes its MCP tool cache instead of recreating it.
+The token intentionally has no time expiration: its lifetime is exactly the
+database-and-OCI incarnation lifetime, allowing a command to survive arbitrarily
+many server restarts without persisting or rotating token bytes. Killing,
+replacing, failing, or removing that incarnation immediately makes the token
+unauthorized.
+The capability is not a user session and the dedicated listener exposes no
+ordinary `/v0` APIs.
+
+When Happy asks an installed MCP tool to run for an agent, it adds the following
+request metadata:
+
+```json
+{
+    "_meta": {
+        "happy2/chat": {
+            "id": "current-chat-cuid2",
+            "token": "signed-chat-capability-jwt"
+        }
+    }
+}
+```
+
+The RS256 chat token has no expiration and is bound to both that chat and the
+specific plugin installation receiving the call. Plugin host chat actions also
+require the running installation's ordinary runtime token; presenting a chat
+token through another installation is rejected. Uninstalling or replacing an
+installation therefore prevents its old chat tokens from being used by a new
+installation. Chat IDs remain immutable and are supplied in metadata and API
+results for correlation, never accepted as mutation input.
 
 The bridge allows at most 128 simultaneous sessions server-wide and 16 per
 authenticated user. Idle sessions close after 15 minutes; inbound requests and
@@ -297,7 +455,9 @@ thumbhash, and SHA-256 checksum.
 
 `plugin_installations` records a separate CUID2 and foreign key to `plugins`,
 plus that instance's container/image choice, lifecycle state, error detail,
-installer, and timestamps. `plugin_installation_variables` records each declared
+installer, tool-sync timestamp, and timestamps. `plugin_mcp_tools` contains the
+last complete MCP discovery keyed by installation and tool name.
+`plugin_installation_variables` records each declared
 value for one installation; secret rows contain authenticated ciphertext rather
 than plaintext. No installation uses `shortName` as identity.
 

package/packages/happy2-server/README.md

@@ -18,6 +18,10 @@ npx happy2
 npx happy2 service start --config ./happy2.toml
 npx happy2 service stop
 
+# Start or stop it as a background process in the current directory
+npx happy2 daemon start --config ./happy2.toml
+npx happy2 daemon stop
+
 # Development, with reload and no configuration file:
 pnpm dev:server
 
@@ -62,6 +66,13 @@ reinstallation. `happy2 service stop` directly stops and removes the macOS Launc
 while on Linux it prints the `sudo` commands that stop, disable, and remove the
 systemd unit.
 
+`happy2 daemon start` starts the all-in-one app in a detached process group and
+returns immediately. It writes `.happy2/happy2.pid` and appends output to
+`.happy2/happy2.log` in the current directory. `happy2 daemon stop` sends the
+whole process group a graceful termination signal, force-stops it if necessary,
+and removes the PID file. Unlike `service start`, daemon mode does not arrange
+automatic startup after a login or reboot.
+
 The service preserves the installation-time working directory, `PATH`, and
 optional `RIG_HOME`. When `--config` is supplied, its path is made
 absolute before installation. Put service secrets and SMTP environment values
@@ -362,13 +373,14 @@ authenticated Unix socket. Configure `[agents]` with the socket, token, Rig
 executable, and server-owned `default_cwd`; clients cannot select filesystem
 paths.
 
-An agent's reasoning effort is durable profile state. Any authenticated user can
-read its current value and the effort levels supported by all of its active Rig
-sessions from `GET /v0/agents/:agentUserId/effort`; only the agent's creator or
-a server administrator can change it with
-`POST /v0/agents/:agentUserId/changeEffort`. A change is applied to every
-existing private Rig session, inherited by sessions created later, reconciled
-again after server restart, and published as a normal `users` sync hint.
+An agent's profile effort is the default for new chat sessions. Each bound chat
+stores its own durable override, exposed to active chat members through
+`GET /v0/chats/:chatId/agents/:agentUserId/effort` and
+`POST /v0/chats/:chatId/agents/:agentUserId/changeEffort`. Changing one chat
+updates only that chat's Rig session, survives restart, and appends an
+`agent_effort_changed` service message to the same chat. Choosing the already
+effective value is a no-op and does not add duplicate history. A newly bound
+chat inherits the agent profile default rather than another chat's override.
 
 The server seeds immutable `Daycare Minimal` and `Daycare Full` definitions from
 the pinned upstream Daycare runtime Dockerfiles. Both use Ubuntu 24.04; Full adds

package/packages/happy2-server/dist/daemon.d.ts

@@ -0,0 +1,39 @@
+export interface DaemonHost {
+    cwd: string;
+    environment: NodeJS.ProcessEnv;
+    executablePath: string;
+    executableArguments: readonly string[];
+    scriptPath: string;
+    directoryCreate(path: string): Promise<void>;
+    fileCreate(path: string, contents: string): Promise<boolean>;
+    fileExists(path: string): Promise<boolean>;
+    fileRead(path: string): Promise<string>;
+    fileRemove(path: string): Promise<void>;
+    processStart(input: {
+        arguments_: readonly string[];
+        cwd: string;
+        environment: NodeJS.ProcessEnv;
+        executablePath: string;
+        logPath: string;
+        pidPath: string;
+    }): Promise<number>;
+    processAlive(pid: number): boolean;
+    processTreeAlive(pid: number): boolean;
+    processTreeSignal(pid: number, signal: NodeJS.Signals): void;
+    wait(milliseconds: number): Promise<void>;
+    log(message: string): void;
+}
+export type ParsedDaemonCommand = {
+    action: "help" | "invalid" | "stop";
+} | {
+    action: "start";
+    configPath?: string;
+};
+export declare function parseDaemonCommand(arguments_: readonly string[]): ParsedDaemonCommand;
+export declare function daemonStart(options: {
+    configPath?: string;
+}, host?: DaemonHost): Promise<void>;
+export declare function daemonStop(host?: DaemonHost): Promise<void>;
+export declare function daemonUsage(): string;
+export declare function createDaemonHost(): DaemonHost;
+//# sourceMappingURL=daemon.d.ts.map

package/packages/happy2-server/dist/daemon.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"daemon.d.ts","sourceRoot":"","sources":["../sources/daemon.ts"],"names":[],"mappings":"AAaA,MAAM,WAAW,UAAU;IACvB,GAAG,EAAE,MAAM,CAAC;IACZ,WAAW,EAAE,MAAM,CAAC,UAAU,CAAC;IAC/B,cAAc,EAAE,MAAM,CAAC;IACvB,mBAAmB,EAAE,SAAS,MAAM,EAAE,CAAC;IACvC,UAAU,EAAE,MAAM,CAAC;IACnB,eAAe,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IAC7C,UAAU,CAAC,IAAI,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,OAAO,CAAC,OAAO,CAAC,CAAC;IAC7D,UAAU,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC,OAAO,CAAC,CAAC;IAC3C,QAAQ,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC;IACxC,UAAU,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IACxC,YAAY,CAAC,KAAK,EAAE;QAChB,UAAU,EAAE,SAAS,MAAM,EAAE,CAAC;QAC9B,GAAG,EAAE,MAAM,CAAC;QACZ,WAAW,EAAE,MAAM,CAAC,UAAU,CAAC;QAC/B,cAAc,EAAE,MAAM,CAAC;QACvB,OAAO,EAAE,MAAM,CAAC;QAChB,OAAO,EAAE,MAAM,CAAC;KACnB,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC;IACpB,YAAY,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC;IACnC,gBAAgB,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC;IACvC,iBAAiB,CAAC,GAAG,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,CAAC,OAAO,GAAG,IAAI,CAAC;IAC7D,IAAI,CAAC,YAAY,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAAC;IAC1C,GAAG,CAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;CAC9B;AAED,MAAM,MAAM,mBAAmB,GACzB;IAAE,MAAM,EAAE,MAAM,GAAG,SAAS,GAAG,MAAM,CAAA;CAAE,GACvC;IAAE,MAAM,EAAE,OAAO,CAAC;IAAC,UAAU,CAAC,EAAE,MAAM,CAAA;CAAE,CAAC;AAE/C,wBAAgB,kBAAkB,CAAC,UAAU,EAAE,SAAS,MAAM,EAAE,GAAG,mBAAmB,CAgCrF;AAED,wBAAsB,WAAW,CAC7B,OAAO,EAAE;IAAE,UAAU,CAAC,EAAE,MAAM,CAAA;CAAE,EAChC,IAAI,GAAE,UAA+B,GACtC,OAAO,CAAC,IAAI,CAAC,CAyCf;AAED,wBAAsB,UAAU,CAAC,IAAI,GAAE,UAA+B,GAAG,OAAO,CAAC,IAAI,CAAC,CA+BrF;AAED,wBAAgB,WAAW,IAAI,MAAM,CAQpC;AA4DD,wBAAgB,gBAAgB,IAAI,UAAU,CAuG7C"}