@mstone6969/vault 0.2.0 → 0.5.0

package/README.md

@@ -30,6 +30,22 @@ await vault.open("alice", "stripe_key") // "sk_live_…"
 Everything is scoped by an owner, so one vault serves many accounts and two
 people can both keep a `token` without seeing each other's.
 
+## How a value is sealed
+
+Every value gets its own **data key**. The value is sealed under that, and only
+the data key is sealed under your master key:
+
+```
+value ──sealed under──▶ data key ──sealed under──▶ master key
+```
+
+Two things follow. Changing the master key re-seals a handful of bytes per
+entry rather than every value, so `rekey` is cheap whatever you keep in there.
+And a data key that leaks opens one value, not all of them.
+
+Values written by earlier versions are sealed under the master key directly;
+they still open, and `rekey` gives them an envelope on the way past.
+
 ## Metadata
 
 A value is sealed, but the facts *about* it usually should not be. `put` takes
@@ -70,9 +86,34 @@ credential is worse than not running it. Change the prefix with
 
 ## Storage
 
-`MemoryStore` ships in the main entry. `SqliteStore` is Bun-only — it imports
-`bun:sqlite`, so it lives behind a subpath and never loads unless you ask for
-it:
+Three stores ship with the package.
+
+**`FileStore`** keeps everything in one encrypted file. The other stores seal
+values and leave the rest in the open — SQLite has an `owner` column and a
+`name` column, so anyone who can read the file learns what you keep even if
+they cannot read it. Here the whole index is inside a single envelope, and what
+leaks at rest is the file's size:
+
+```ts
+import { FileStore } from "@mstone6969/vault/stores/file"
+
+const store = new FileStore("./secrets.vault", fileKey("/etc/vault.key"))
+```
+
+Give the file a key of its own, or hand it the vault's — sharing means one key
+opens both layers. It is loaded and written whole, so it suits hundreds of
+secrets and one writer, not millions and many.
+
+Writes go to a temporary file, are flushed to disk, and are renamed into place,
+so neither a crash nor a power loss leaves a half-written index — which matters
+more here than elsewhere, because the whole index is one envelope and a torn
+file would lose every record rather than one. Nothing locks the file, so two
+writers on the same path are still last-write-wins. Unlike `SqliteStore`, it
+uses only `node:fs`, so it runs on Node as well as Bun.
+
+**`MemoryStore`** ships in the main entry. **`SqliteStore`** is Bun-only — it
+imports `bun:sqlite`, so it lives behind a subpath and never loads unless you
+ask for it:
 
 ```ts
 import { SqliteStore } from "@mstone6969/vault/stores/sqlite"
@@ -89,6 +130,7 @@ methods, all scoped by owner, all dealing in sealed strings and never plaintext:
 type VaultStore = {
     get(owner: string, name: string): Promise<SecretRecord | null>
     list(owner: string): Promise<SecretRecord[]>
+    all(): Promise<SecretRecord[]>
     put(record: {
         owner: string
         name: string
@@ -107,9 +149,125 @@ decrypting to something wrong — both cases are covered by tests.
 
 The key never leaves your process, and the package never writes it anywhere.
 
+## Lifecycle
+
+An entry can be more than a value:
+
+```ts
+await vault.put("alice", "region", "eu-west-1", { open: true })   // readable
+await vault.put("alice", "root_ca", pem, { final: true })         // written once
+await vault.put("alice", "token", value, { expiresAt: tomorrow }) // stops working
+await vault.rotate("alice", "deploy", next)                       // keeps the old one
+```
+
+- **`open`** stores the value in the clear, and `read()` gives it back. For
+  configuration rather than credentials; a sealed entry answers 403.
+- **`final`** refuses every future replacement — delete it or live with it.
+- **`expiresAt`** stops the entry resolving once it passes. `purgeExpired()`
+  clears them out when you are ready.
+- **`rotate`** keeps what it replaced, up to `historyLimit` (5 by default), and
+  `versions()` opens them. A job that read the credential moments before a
+  rotation can still finish on what it was given.
+
+## Rotating without knowing the value
+
+An entry can carry a **rotation policy**: how to make its next value. That is a
+recipe, never a value, so it is stored in the open beside the metadata — and
+whatever runs the rotation is told how to make the next password without being
+told the current one.
+
+```ts
+await vault.put("alice", "db", firstPassword, {
+    metadata: { username: "ada" },
+    rotation: { kind: "random", length: 24, every: 86_400 },
+})
+
+await vault.rotate("alice", "db")   // no value: the policy makes one
+```
+
+For a credential only the far end can mint, name a generator instead. The vault
+stores the *name*; the function stays in your process:
+
+```ts
+const vault = new Vault({
+    key,
+    store,
+    generators: {
+        provider: async ({ arguments: args }) => api.mintKey(args.account),
+    },
+})
+
+await vault.put("alice", "api", currentKey, {
+    rotation: { kind: "generator", generator: "provider", arguments: { account: "acct_123" } },
+})
+```
+
+A generator is told which entry is being rotated and its policy's arguments —
+deliberately not the value it is replacing. One that needs the old value can
+ask the vault for it.
+
+`rotationDue(now?)` reports entries whose `every` has elapsed since they were
+last rotated. Nothing rotates them for you; schedule it and act on the list.
+
+Rotating keeps everything the entry already had — its metadata, its policy, its
+expiry — and records `rotatedAt`. Only the value changes.
+
+Anything you leave out of `put` stays as it was, so rotating a credential does
+not quietly forget what kind it is or when it expires.
+
+`reseal()` re-seals values under fresh data keys without changing the master
+key — cheap hygiene, so the ciphertext of an unchanged secret stops being
+comparable between two copies of the database.
+
+## Where the key comes from
+
+```ts
+new Vault({ key: envKey("VAULT_KEY"), store })    // an environment variable
+new Vault({ key: fileKey("/etc/vault.key"), store })  // a file
+new Vault({ key: staticKey(material), store })    // one you already have
+```
+
+A provider is one method — write your own for a KMS or anything else. It is
+called the first time a key is actually needed, not when the vault is built, so
+a vault nobody uses never reaches for one.
+
+## Watching what happens
+
+```ts
+new Vault({
+    key,
+    store,
+    onAccess: (event) => log(event), // put, open, read, remove, rotate, rekey, denied
+})
+```
+
+Every refusal is reported too, with the reason — `final`, `sealed`, `expired`.
+The hook is never awaited and its failures are swallowed: an audit trail that
+throws must not take the vault with it.
+
+### Changing the key
+
+`rekey` opens every value with the current key and re-seals it under a new one:
+
+```ts
+const report = await vault.rekey(nextKey)
+// { rekeyed: 128, failed: [] }
+```
+
+The old key stays readable for the life of that vault, so a run that stops
+halfway leaves a mix that still opens. Construct the next one with both until
+you are sure:
+
+```ts
+new Vault({ key: nextKey, previousKeys: [oldKey], store })
+```
+
+A value that will not open under any key it holds is **left exactly as it was**
+and named in `failed` — re-sealing what cannot be read would only destroy it.
+
 > [!WARNING]
-> Losing the key loses every value stored under it. There is no recovery path,
-> by design. Back it up where you would back up a password.
+> Losing every key loses every value sealed under them. Rekey before you retire
+> a key, and back the current one up where you would back up a password.
 
 ## API
 
@@ -117,8 +275,16 @@ The key never leaves your process, and the package never writes it anywhere.
 | --- | --- |
 | `new Vault({ key, store, prefix? })` | Key is base64 or an imported `CryptoKey` |
 | `put(owner, name, value, metadata?)` | Store or replace; returns a summary, no value |
+| `rekey(nextKey)` | Re-seal everything under a new key; returns a report |
 | `list(owner)` | Names, dates and metadata, sorted by name |
 | `open(owner, name)` | The plaintext — keep it in memory |
+| `read(owner, name)` | The value of an entry stored in the open |
+| `rotate(owner, name, value?, options?)` | Replace, keeping the old value; without one, the policy makes it |
+| `rotationDue(now?)` | Entries whose rotation interval has elapsed |
+| `randomValue(length?, alphabet?)` | An unbiased random string |
+| `versions(owner, name)` | Previous values, newest first |
+| `reseal(owner?)` | Fresh data keys, same master key |
+| `purgeExpired(now?)` | Delete entries whose time is up |
 | `has(owner, name)` | Whether it exists |
 | `remove(owner, name)` | `false` if there was nothing to remove |
 | `resolve(owner, values)` | Substitute `@vault:` references |
@@ -130,6 +296,22 @@ ciphertext problems throw `VaultKeyError`.
 
 ## Versions
 
+**0.5.0** — envelope encryption (each value gets its own data key), entry
+lifecycle (`open`, `final`, `expiresAt`, `rotate`/`versions`, `reseal`,
+`purgeExpired`), rotation policies that say how to make the next value without
+storing it, key providers (`envKey`, `fileKey`, `staticKey`), an `onAccess`
+audit hook, `FileStore` — an encrypted single-file store that hides names as
+well as values — and a generated API reference in `docs/`.
+
+Breaking: `put`'s fourth argument is now an options object — `put(owner, name,
+value, { metadata })` rather than `put(owner, name, value, metadata)` — and
+`VaultStore.put` takes a whole record. Values written by 0.2.0 and earlier open
+unchanged.
+
+**0.3.0** — `rekey(nextKey)` re-seals every value under a new key, and
+`previousKeys` lets a vault open values sealed under keys it has retired.
+`VaultStore` gains `all()`, which a custom store must implement.
+
 **0.2.0** — `put` takes optional non-secret `metadata`, and `SecretRecord`
 carries it. Existing calls keep working: metadata defaults to `{}`. A
 `SqliteStore` table written by 0.1.0 gains the column on open.
@@ -139,6 +321,16 @@ carries it. Existing calls keep working: metadata defaults to `{}`. A
 ## Development
 
 ```bash
-bun test
+bun test              # the suite
+bun run test:coverage # the suite, and fail if anything in src is untested
 bun run typecheck
+bun run docs          # generate docs/ from the TSDoc comments
+bun run docs:check    # fail if any exported member is undocumented
 ```
+
+Every line and function in `src` is covered, and every exported member carries
+TSDoc; `test:coverage` and `docs:check` enforce both, and `prepublishOnly` runs
+them. Bun accepts `coverageThreshold` in bunfig.toml but does not act on it, so
+the coverage check reads the lcov report itself and exits non-zero on a gap.
+
+The generated reference lives in `docs/` and ships with the package.

package/dist/crypto.d.ts

@@ -1,7 +1,104 @@
-/** A new random key, base64 encoded — store it somewhere safe. */
+/**
+ * A new random key, base64 encoded — store it somewhere safe.
+ *
+ * @returns 32 random bytes, base64. Nothing keeps a copy, so a key that is lost
+ *   takes every value sealed under it with it.
+ * @remarks
+ * Used for master keys you generate once and keep, and — inside the vault — for
+ * the throwaway data key minted per written value.
+ * @example
+ * ```ts
+ * import { generateKey, importKey, seal } from "@mstone6969/vault"
+ *
+ * const material = generateKey()
+ * const key = await importKey(material)
+ * const sealed = await seal(key, "hunter2")
+ * ```
+ * @see {@link importKey} to turn the string back into a usable key.
+ */
 export declare function generateKey(): string;
-/** Imports a base64 key produced by `generateKey`. */
+/**
+ * Imports a base64 key produced by {@link generateKey}.
+ *
+ * @param base64Key The key material, base64 encoded, decoding to exactly 32
+ *   bytes.
+ * @returns A key usable with {@link seal} and {@link open}.
+ * @throws {@link VaultKeyError} When the decoded material is not 32 bytes. Note
+ *   that base64 decoding is lenient: rubbish that is not base64 at all decodes
+ *   to too few bytes and surfaces here as a length complaint rather than a
+ *   parse error.
+ * @remarks
+ * The imported key is not extractable, so the raw bytes cannot be read back out
+ * of it — a value only ever leaves via {@link open}.
+ * @example
+ * ```ts
+ * import { importKey, MemoryStore, Vault } from "@mstone6969/vault"
+ *
+ * const key = await importKey(process.env.VAULT_KEY!)
+ * const vault = new Vault({ key, store: new MemoryStore() })
+ * ```
+ */
 export declare function importKey(base64Key: string): Promise<CryptoKey>;
+/**
+ * Seals a value under a key.
+ *
+ * @param key The key to seal under.
+ * @param plaintext What to seal.
+ * @returns `iv:payload`, both base64. A fresh IV every time, so the same value
+ *   sealed twice gives two different results.
+ * @remarks
+ * That the output differs every time is the point: an observer with the store
+ * in front of them cannot tell that two entries hold the same password, nor
+ * that a value was replaced with itself. It also means a sealed string is no
+ * good as a cache key or an equality check.
+ *
+ * Nothing about the key is written into the output, so the caller must
+ * remember which key sealed what — the vault does that by keeping each value's
+ * data key beside it in {@link SecretRecord.sealedKey}.
+ * @example
+ * ```ts
+ * import { generateKey, importKey, open, seal } from "@mstone6969/vault"
+ *
+ * const key = await importKey(generateKey())
+ * const sealed = await seal(key, "s3cret")
+ * sealed.split(":").length // 2
+ * await open(key, sealed) // "s3cret"
+ * ```
+ */
 export declare function seal(key: CryptoKey, plaintext: string): Promise<string>;
+/**
+ * Opens a value sealed by {@link seal}.
+ *
+ * @param key The key it was sealed under.
+ * @param sealed The `iv:payload` string to open.
+ * @returns The plaintext.
+ * @throws {@link VaultKeyError} When the key is wrong, the value has been
+ *   altered, or it is not in `iv:payload` form. A wrong key fails rather than
+ *   returning nonsense, because GCM authenticates what it decrypts.
+ * @remarks
+ * That failure mode is worth relying on. A caller does not need to check
+ * whether what came back looks plausible: if this returns at all, the value is
+ * byte for byte what was sealed, under the key that sealed it. It is also why
+ * {@link Vault.rekey} can try each key in turn and know which one was right,
+ * and why a store that silently corrupts a record produces an error rather
+ * than a credential that fails somewhere far away.
+ *
+ * The error deliberately does not say which of the three went wrong: telling
+ * an attacker apart from a typo is not worth telling an attacker anything.
+ * @example
+ * ```ts
+ * import { generateKey, importKey, open, seal, VaultKeyError } from "@mstone6969/vault"
+ *
+ * const key = await importKey(generateKey())
+ * const other = await importKey(generateKey())
+ * const sealed = await seal(key, "s3cret")
+ *
+ * try {
+ *     await open(other, sealed)
+ * } catch (error) {
+ *     error instanceof VaultKeyError // true — never a wrong plaintext
+ * }
+ * ```
+ */
 export declare function open(key: CryptoKey, sealed: string): Promise<string>;
 //# sourceMappingURL=crypto.d.ts.map

package/dist/crypto.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"crypto.d.ts","sourceRoot":"","sources":["../src/crypto.ts"],"names":[],"mappings":"AAUA,kEAAkE;AAClE,wBAAgB,WAAW,IAAI,MAAM,CAEpC;AAED,sDAAsD;AACtD,wBAAsB,SAAS,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,SAAS,CAAC,CAQrE;AAED,wBAAsB,IAAI,CAAC,GAAG,EAAE,SAAS,EAAE,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAQ7E;AAED,wBAAsB,IAAI,CAAC,GAAG,EAAE,SAAS,EAAE,MAAM,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAkB1E"}
+{"version":3,"file":"crypto.d.ts","sourceRoot":"","sources":["../src/crypto.ts"],"names":[],"mappings":"AA4BA;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,WAAW,IAAI,MAAM,CAEpC;AAED;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,wBAAsB,SAAS,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,SAAS,CAAC,CAQrE;AAED;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,wBAAsB,IAAI,CAAC,GAAG,EAAE,SAAS,EAAE,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAQ7E;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AACH,wBAAsB,IAAI,CAAC,GAAG,EAAE,SAAS,EAAE,MAAM,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAkB1E"}

package/dist/errors.d.ts

@@ -1,13 +1,131 @@
-/** A caller mistake: a bad name, an empty value, a missing secret. */
+/**
+ * A caller mistake: a bad name, an empty value, a missing secret.
+ *
+ * @remarks
+ * Everything the vault throws on purpose is a `VaultError`, so a caller can
+ * tell "you asked for something that cannot be done" apart from a bug, and
+ * answer accordingly, with one `instanceof`.
+ *
+ * @example Turning a vault call into an HTTP response
+ * ```ts
+ * import { Vault, VaultError, MemoryStore, generateKey } from "@mstone6969/vault"
+ *
+ * const vault = new Vault({ key: generateKey(), store: new MemoryStore() })
+ *
+ * try {
+ *     return new Response(await vault.open("alice", "stripe"))
+ * } catch (error) {
+ *     if (error instanceof VaultError) {
+ *         return new Response(error.message, { status: error.status })
+ *     }
+ *     throw error
+ * }
+ * ```
+ *
+ * @see {@link VaultKeyError} for the key and ciphertext failures.
+ */
 export declare class VaultError extends Error {
-    /** Suggested HTTP status, for callers putting this behind an API. */
+    /**
+     * Suggested HTTP status, for callers putting this behind an API.
+     *
+     * @remarks
+     * It is a suggestion, not a promise about transport: nothing in the
+     * vault speaks HTTP. It exists so a handler can map a failure to a
+     * response without knowing which check inside the vault failed.
+     *
+     * The statuses actually thrown:
+     *
+     * - `422` — bad input: a name that is not 1–64 characters of letters,
+     *   numbers, dot, dash or underscore; an empty value; a `randomValue`
+     *   length below one or an alphabet under two characters; a rotation
+     *   asked of an entry with no rotation policy.
+     * - `404` — no secret under that name for that owner.
+     * - `409` — the entry is `final`, so it can be deleted but not
+     *   replaced.
+     * - `403` — the entry is sealed, so `read` will not hand it back.
+     *   `open` is the only way out.
+     * - `410` — the entry's `expiresAt` has passed. The record is still
+     *   there; it just cannot be used.
+     * - `501` — the entry's rotation policy names a generator this vault
+     *   was not constructed with.
+     * - `500` — {@link VaultKeyError}'s default: a key or ciphertext
+     *   problem, which is the operator's fault rather than the caller's.
+     *
+     * @defaultValue 422
+     */
     readonly status: number;
+    /**
+     * @param message What the caller did that the vault would not do. Names
+     *   and owners appear in it; secret values never do, so it is safe to log.
+     * @param status Suggested HTTP status. See {@link VaultError.status}.
+     */
     constructor(message: string, 
-    /** Suggested HTTP status, for callers putting this behind an API. */
+    /**
+     * Suggested HTTP status, for callers putting this behind an API.
+     *
+     * @remarks
+     * It is a suggestion, not a promise about transport: nothing in the
+     * vault speaks HTTP. It exists so a handler can map a failure to a
+     * response without knowing which check inside the vault failed.
+     *
+     * The statuses actually thrown:
+     *
+     * - `422` — bad input: a name that is not 1–64 characters of letters,
+     *   numbers, dot, dash or underscore; an empty value; a `randomValue`
+     *   length below one or an alphabet under two characters; a rotation
+     *   asked of an entry with no rotation policy.
+     * - `404` — no secret under that name for that owner.
+     * - `409` — the entry is `final`, so it can be deleted but not
+     *   replaced.
+     * - `403` — the entry is sealed, so `read` will not hand it back.
+     *   `open` is the only way out.
+     * - `410` — the entry's `expiresAt` has passed. The record is still
+     *   there; it just cannot be used.
+     * - `501` — the entry's rotation policy names a generator this vault
+     *   was not constructed with.
+     * - `500` — {@link VaultKeyError}'s default: a key or ciphertext
+     *   problem, which is the operator's fault rather than the caller's.
+     *
+     * @defaultValue 422
+     */
     status?: number);
 }
-/** The key is the wrong shape, or cannot open what it was given. */
+/**
+ * The key is the wrong shape, or cannot open what it was given.
+ *
+ * @remarks
+ * Thrown for a base64 key that is not 32 bytes, a sealed value not in
+ * `iv:payload` form, and a value that will not open — which covers both the
+ * wrong key and a value someone has altered, since GCM authenticates what it
+ * decrypts and cannot tell you which it was. The key providers throw it too,
+ * when the environment variable is unset or the key file is missing or empty.
+ *
+ * Its status is 500 rather than a 4xx because a request that reaches this did
+ * nothing wrong: the vault is misconfigured, or its data no longer matches its
+ * key.
+ *
+ * @example Distinguishing a key problem from a caller problem
+ * ```ts
+ * import { importKey, VaultKeyError } from "@mstone6969/vault"
+ *
+ * try {
+ *     await importKey(process.env.VAULT_KEY!)
+ * } catch (error) {
+ *     if (error instanceof VaultKeyError) {
+ *         console.error("vault key is unusable:", error.message)
+ *         process.exit(1)
+ *     }
+ *     throw error
+ * }
+ * ```
+ *
+ * @see {@link VaultError} for the mistakes callers can fix themselves.
+ */
 export declare class VaultKeyError extends VaultError {
+    /**
+     * @param message What was wrong with the key or the sealed value. It never
+     *   says which key was tried or what the value held.
+     */
     constructor(message: string);
 }
 //# sourceMappingURL=errors.d.ts.map

package/dist/errors.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"errors.d.ts","sourceRoot":"","sources":["../src/errors.ts"],"names":[],"mappings":"AAAA,sEAAsE;AACtE,qBAAa,UAAW,SAAQ,KAAK;IAG7B,qEAAqE;IACrE,QAAQ,CAAC,MAAM,EAAE,MAAM;gBAFvB,OAAO,EAAE,MAAM;IACf,qEAAqE;IAC5D,MAAM,GAAE,MAAY;CAKpC;AAED,oEAAoE;AACpE,qBAAa,aAAc,SAAQ,UAAU;gBAC7B,OAAO,EAAE,MAAM;CAI9B"}
+{"version":3,"file":"errors.d.ts","sourceRoot":"","sources":["../src/errors.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,qBAAa,UAAW,SAAQ,KAAK;IAQ7B;;;;;;;;;;;;;;;;;;;;;;;;;;;OA2BG;IACH,QAAQ,CAAC,MAAM,EAAE,MAAM;IAnC3B;;;;OAIG;gBAEC,OAAO,EAAE,MAAM;IACf;;;;;;;;;;;;;;;;;;;;;;;;;;;OA2BG;IACM,MAAM,GAAE,MAAY;CAKpC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AACH,qBAAa,aAAc,SAAQ,UAAU;IACzC;;;OAGG;gBACS,OAAO,EAAE,MAAM;CAI9B"}

package/dist/index.d.ts

@@ -1,6 +1,8 @@
 export * from "./vault";
 export * from "./crypto";
 export * from "./errors";
+export * from "./providers";
 export * from "./stores/memory";
+export * from "./stores/file";
 export * from "./types";
 //# sourceMappingURL=index.d.ts.map

package/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAQA,cAAc,SAAS,CAAA;AACvB,cAAc,UAAU,CAAA;AACxB,cAAc,UAAU,CAAA;AACxB,cAAc,iBAAiB,CAAA;AAC/B,cAAc,SAAS,CAAA"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAQA,cAAc,SAAS,CAAA;AACvB,cAAc,UAAU,CAAA;AACxB,cAAc,UAAU,CAAA;AACxB,cAAc,aAAa,CAAA;AAC3B,cAAc,iBAAiB,CAAA;AAC/B,cAAc,eAAe,CAAA;AAC7B,cAAc,SAAS,CAAA"}