@datarails-ai/dr-cli 0.0.1-locked → 1.6.71

package/dist/skills/dr-cli/reference/multi-product.md

@@ -0,0 +1,180 @@
+# `dr multi-product` — product-content catalog & per-org assignment
+
+The `multi-product` microservice (`/api/multi-product/v1/...`) is the
+source of truth for two things:
+
+1. **The catalog of available "product contents"** — every row Datarails
+   can possibly assign to an organization, tagged with a `type`
+   discriminator (`core_interface`, `dataset`, `product`, …).
+2. **The per-organization assignment** — which subset of that catalog a
+   given org is entitled to, bucketed by `type`.
+
+Two read endpoints + one *replace-the-whole-list* write endpoint. The
+write is destructive in spirit (the server overwrites the org's full
+list with whatever body you send) so it's gated behind a two-step
+confirm token — same flow as `dr entities delete`.
+
+## Subcommands
+
+All take `--server <key>` (required) and `--account <email>` (when
+multiple identities are stored). Reads accept `--json` for raw
+pass-through; `set` accepts `--json` to emit the server's
+`{"status":"ok"}` ack verbatim.
+
+### Catalog (global)
+
+- `dr multi-product product-content list` — list every product-content
+  row the service knows about. Renders an `ID | NAME | TYPE` table; use
+  `--json` for parseable output. Empty → `(no product contents)`.
+  → `GET /api/multi-product/v1/product_content/list`
+
+  Use this to discover which `(id, name)` pairs are valid for the
+  `items` arrays inside the per-org body — names alone don't bind, the
+  server matches on the integer `id`.
+
+### Per-organization assignment
+
+- `dr multi-product org-products list <org_id>` — show the products
+  assigned to one org, grouped by `type`. The default text form prints
+  each type bucket as a header with `<id>\t<name>` rows underneath;
+  `--json` returns the raw `[{type, items:[{id,name}]}]` shape.
+  → `GET /api/multi-product/v1/organizations/<org_id>/products`
+
+- `dr multi-product org-products set <org_id> --file <path>
+  [--db-only] [--confirm-token <tok>]` — **replace** the org's full
+  product list with the JSON in `<path>`. Two-step confirm gated.
+  → `PUT /api/multi-product/v1/organizations/<org_id>/products[?db_only=true]`
+  → server replies `{"status":"ok"}` on success
+
+  **The body has replace semantics — anything not in the file is
+  removed.** Always read the current state first (`org-products list`)
+  and either edit that file or apply your delta on top of it. Sending a
+  partial body silently revokes everything you forgot.
+
+  **`--db-only` controls whether the data importer runs.** Omit it (the
+  default) when you want the user to actually have data for the new
+  product — the server inserts the catalog row AND kicks off the
+  data-import workflow. Pass `--db-only` when you only want the
+  product row to exist in the MP DB (e.g. provisioning placeholder /
+  fixing an out-of-sync catalog) — the server skips the importer
+  entirely. Always ask the user which mode they want before running.
+  The plan-phase output prints a `MODE:` line (`full` vs `db-only`) so
+  you can double-check before confirming.
+
+## `--file` body shape
+
+`org-products set` takes a JSON array of type buckets — identical to the
+GET response, so a round-trip "list → edit → set" works without
+reshaping. Schema:
+
+```json
+[
+  {
+    "type": "core_interface",
+    "items": [
+      { "id": 1, "name": "full_fpna" }
+    ]
+  },
+  {
+    "type": "dataset",
+    "items": [
+      { "id": 5, "name": "native_fpna" }
+    ]
+  },
+  {
+    "type": "product",
+    "items": [
+      { "id": 11, "name": "ai_agents" }
+    ]
+  }
+]
+```
+
+- Root must be an array (not an object).
+- Each entry needs a non-empty string `type` and an `items` array (may
+  be empty to clear that bucket).
+- Each item needs an integer `id` and a string `name`. The server
+  matches on `id`; the `name` is for human readability.
+- Parser errors are prefixed with the offending location, e.g.
+  `--file[0].items[0].id: expected an integer`.
+
+## Two-step confirm (the `set` gate)
+
+`org-products set` mirrors the `delete`-style flow. The token is bound
+to `(resource:'org-products', id:<org_id>, verb:<verb>)`. `<verb>` is
+`replace` for the default full-import flow and `replace-db-only` when
+`--db-only` is passed — a token issued for one mode cannot be reused
+in the other, and a token issued for org 42 cannot be reused against
+org 99.
+
+1. **Plan phase** (no `--confirm-token`): the CLI parses + validates
+   the `--file`, prints what it's *about to apply* (one line per type
+   bucket with count + `id:name` pairs), and emits the exact confirm
+   command with a fresh token. No HTTP call is made.
+2. **Apply phase**: re-run the command with `--confirm-token <tok>`.
+   The body is PUT and the server's `{"status":"ok"}` is shown
+   (or emitted as raw JSON under `--json`).
+
+Token TTL is 10 minutes — past that, re-run step 1.
+
+For prod (`US`/`US2`/`UK`/`CA`/`EU`/`DEMO`), get the user's in-chat "yes" before
+re-invoking with the token; the binary's interactive gate then has the user
+type a challenge word in a dialog, same as any other destructive write — see
+[safety.md](safety.md).
+
+## Workflow recipe — "give this org access to product X"
+
+```
+# 1. Pick the org id (organizations list → find it)
+dr organizations list --server US --json | jq '.[] | {id,name}'
+
+# 2. See what's available in the catalog
+dr multi-product product-content list --server US
+
+# 3. Read the org's current list as the baseline
+dr multi-product org-products list 42 --server US --json > /tmp/org42.json
+
+# 4. Edit /tmp/org42.json to add the new product
+#    (e.g. append { "id": 11, "name": "ai_agents" } to the "product" bucket)
+
+# 5. Plan phase — review what's about to change
+dr multi-product org-products set 42 --file /tmp/org42.json --server US
+
+# 6. Apply with the token printed in step 5
+dr multi-product org-products set 42 --file /tmp/org42.json --server US \
+  --confirm-token <tok>
+```
+
+The "always read first" pattern matters here because the PUT replaces.
+Hand-crafting the file without listing first risks dropping buckets you
+didn't realise existed.
+
+## Foot-guns
+
+- **Replace, not merge.** `set` overwrites the whole list. Read → edit
+  → write. If the user asks to "add product X" or "remove product Y",
+  the recipe still routes through a full-list PUT.
+- **`id` is what binds**, not `name`. A typo in `name` is silently
+  accepted at parse time. Cross-check ids against `product-content list`.
+- **`type` is free-form**, not a closed enum. The service may add new
+  bucket types over time (the catalog is the source of truth) — don't
+  hard-code the three documented buckets (`core_interface`, `dataset`,
+  `product`) in scripts; iterate whatever the server returns.
+- **Empty body clears everything**. Sending `[]` is treated as a valid
+  replace and revokes all assignments. The plan-phase output flags this
+  with `new list: (empty — clears all assignments)`; double-check
+  before you confirm.
+- **Token binds to org id.** Generated one for org 42, paste it against
+  org 99 — the CLI rejects it with `confirm token does not match this
+  resource / action`. Re-run step 1 for the correct id.
+- **Token also binds to `--db-only`.** A plan-phase token issued
+  without `--db-only` can't be applied with `--db-only` (or vice
+  versa) — the CLI rejects it with the same `does not match this
+  resource / action` error. Re-run the plan phase with the mode you
+  actually want.
+- **Choose the mode deliberately.** `--db-only` is a row-only
+  provisioning lever — the server will NOT start the data-import
+  workflow that normally fires when a product is added. If the user
+  expects their data to actually show up in the new product, you must
+  omit `--db-only` (the default). Confirm with the user which they
+  want before confirming the plan-phase token.

package/dist/skills/dr-cli/reference/reconciliation-mec.md

@@ -0,0 +1,76 @@
+# Reconciliation + MEC close-dates
+
+Alias `recon`. For workflow-engine commands (`mec workflow …`) see
+[workflows.md](workflows.md).
+
+## Read
+
+- `reconciliation accounts list | entities | entity-currencies | info | progress | settings`.
+- `reconciliation processes dates | accounts`.
+- `reconciliation evidences list | get | process | supporting | file`.
+  The v2 verbs (`process`/`supporting`/`file`/`create`) accept either
+  `--process <uuid>` **or** `--entity <name> --date <YYYY-MM-DD|YYYY-MM>` (which
+  resolves the UUID via the accounts endpoint). The v1 path (`list`, and `file
+  --account`) is deprecated and prints a stderr warning.
+- `reconciliation filebox list | get | progress | unlinked`.
+- `reconciliation audit status`.
+
+## Write
+
+Account assignment / sign-off (all take the bank-account UUID via
+`--account-uuid` — see the flag note below):
+
+- `reconciliation accounts update-settings --file <p>` — admin-only PATCH.
+  Two-step confirm; the token binds to a hash of the file's rows, so editing
+  the file between plan and confirm invalidates it.
+- `reconciliation accounts set-assignee <account_uuid> --date <YYYY-MM-DD>
+  --type Preparer|Reviewer --user-id <n> [--user-name <s> --user-email <s>]` —
+  resets any prior sign-off; name/email are auto-fetched if not supplied.
+  Two-step confirm: first run prints the current holder + a token; re-run
+  with `--confirm-token` to actually write.
+- `reconciliation accounts set-assignee --file <csv> --date <YYYY-MM-DD>` —
+  the bulk form, for more than a handful of accounts. Header
+  `account_id,type,user_id[,user_name,user_email]`, one row per
+  (account, role); blank name/email cells are looked up once per user id.
+  One plan and one token cover the whole file (the token binds to a hash of
+  the rows and the date). The plan reports rows to change, rows skipped
+  because the slot already holds that user, and how many sign-offs the write
+  resets. Every account is checked before anything is written, and the
+  write goes out in PATCHes of 100 accounts. If one fails, the error says
+  how many accounts landed; re-run the same file without a token and the
+  new plan covers only the rest. Do not script a loop of single
+  `set-assignee` calls for this.
+- `reconciliation accounts clear-assignee <account_uuid> --date <YYYY-MM-DD>
+  --type Preparer|Reviewer` — unassigns (preserves due_date, resets sign-off).
+  Two-step confirm.
+- `reconciliation accounts set-due-date <account_uuid> --date <YYYY-MM-DD>
+  --type Preparer|Reviewer (--due-date <YYYY-MM-DD> | --epoch <n> | --clear)`.
+  Two-step confirm.
+- `reconciliation accounts sign <account_uuid> --date <YYYY-MM-DD>
+  --type Preparer|Reviewer [--revoke]`. Two-step confirm; sign and revoke
+  tokens are not interchangeable.
+
+Evidences / filebox:
+
+- `reconciliation evidences create --file <path> --account-uuid <uuid>
+  --amount <n> [--note <s>] [--name <s>]` — multipart upload of a v2 supporting
+  item. `--account-uuid` / `--amount` / `--note` are repeatable and
+  index-aligned for attaching to multiple accounts.
+- `reconciliation filebox create --file <p>` (`--effective-since` accepts
+  `YYYY-MM` or `YYYY-MM-DD`), `reconciliation filebox delete` (two-step confirm).
+
+**Flag note:** the bank-account-scoped subcommands take `--account-uuid <uuid>`
+for the bank-account UUID. (`--account` is reserved CLI-wide for the auth-identity
+selector.)
+
+## MEC close-dates
+
+- `mec close-dates get` — the org's close-date map (whole org, or `--year`).
+- `mec close-dates set --file <p>` — admin-only PUT; replaces the org's
+  close-date map from a JSON file.
+
+## Customer-facing docs (KB)
+
+Help Center → the **"Month End Close"** category. Find current articles with `dr kb search "month end close reconciliation"` (or
+browse `dr kb categories` / `dr kb sections`). Cite the article; don't
+paraphrase from memory.

package/dist/skills/dr-cli/reference/rh-config.md

@@ -0,0 +1,84 @@
+# `dr rh_config` — legacy RH_CONFIG inspection (read-only)
+
+RH_CONFIG is the **legacy** mechanism by which a filebox's "config workbook"
+(the Excel attached to the bucket with `is_config=True`) defines its
+TableTemplates. The Excel contains a sheet literally named `RH_Config` that
+the monolith's parser reads via `LEGACY_get_document_data_from_workbook_rh_config`
+(`HippiWeb/Documents/utils_cython.py:233`) to build the templates and their
+LUTs. A template generated from that path carries `is_rh_config: true`
+(true when `TableTemplate.config == ''` server-side).
+
+The `rh_config` family is purely read-only — five GETs for inspecting
+legacy state during audits or debugging. No writes; if you need to upload a
+new config workbook or trigger a rescan, use the standard `filebox` /
+`buckets` write surfaces (which the FE drives).
+
+## Subcommands
+
+All take `--server <key>` (required) and `--account <email>` (when multiple
+identities are stored). Every read accepts `--json` for raw pass-through.
+
+- `dr rh_config config <bucket-id>` — show the config `DocumentVersion`
+  attached to a bucket (the workbook with the `RH_Config` sheet). Renders a
+  kv summary: version id, document id, name, version number, status,
+  created timestamp. `(no config version)` when the bucket has never had a
+  config workbook.
+  → `GET /api/buckets/<id>/config`
+
+- `dr rh_config tables <bucket-id>` — show the config file URL plus the
+  table names defined by the workbook (the names of `ACTIVE`, non-archive
+  `TableTemplate` rows that belong to the bucket's data model). Useful
+  for "what does this filebox's config say it should create?"
+  → `GET /api/buckets/admin/<id>/config_update`
+
+- `dr rh_config download <bucket-id> [--output <path>]` — download the raw
+  config `.xlsx`. Default destination is `bucket_<id>_config.xlsx` in the
+  current directory; `--output -` streams bytes to stdout (pipe-friendly).
+  → `GET /api/buckets/admin/<id>/file`
+  - **Broken — don't use.** The endpoint doesn't accept the CLI's JWT, so the
+    command writes the auth login HTML page to disk instead of the workbook
+    (exit 0, no error). **Workaround:** get the config version's `id` and
+    `document` from `dr rh_config config <bucket-id> --json`, then
+    `dr filebox download <document> --doc-version <id> --output <path>`.
+
+- `dr rh_config doc-templates <document-id> [--legacy-only]` — list
+  templates associated with a document, with the `is_rh_config` flag
+  surfaced. `--legacy-only` filters to RH_CONFIG-derived rows (the usual
+  ask during a legacy audit). The document id is the `Document` id (not a
+  version id, not a bucket id).
+  → `GET /api/documents/<id>/template_configs`
+
+- `dr rh_config version-templates <version-id> [--v2] [--legacy-only]` —
+  list templates referenced by a document version (functions + extables
+  combined). `--v2` switches to the v2 path that also reports
+  `split_obj_exists`, the indicator the FE uses to show "this version is
+  split". The version id is a `DocumentVersion` id (get it from
+  `filebox versions <doc_id>`).
+  → `GET /api/documents/versions/<id>/get_functions_templates`
+  → with `--v2`: `GET /api/documents/v2/versions/<id>/get_functions_templates`
+
+## When to reach for `rh_config` instead of `templates` / `filebox`
+
+- "Is this template RH_CONFIG-derived?" → `dr rh_config doc-templates <doc>
+  --legacy-only` (the regular `templates list` doesn't render the flag).
+- "What does the config workbook look like for this filebox?" → `dr
+  rh_config config <bucket> --json` for the version `id` + `document`, then
+  `dr filebox download <document> --doc-version <id>` to grab the .xlsx
+  (not `rh_config download` — it saves the login page, see above). Or `dr
+  rh_config tables <bucket>` for just the table names.
+- "Did this version reference any legacy-config tables?" → `dr rh_config
+  version-templates <vid> --legacy-only`.
+
+For non-legacy template operations (sample data, distinct, aggregate,
+create, set field type, …) keep using `dr templates ...` — RH_CONFIG is
+about the legacy plumbing only.
+
+## Why this family is read-only
+
+RH_CONFIG is on the deprecation runway: the monolith's
+`utils_cython.py:72` literally says `# !!! this one should be removed
+after getting rid of RH_CONFIG !!`. Writes against the RH_CONFIG path
+exist (uploading a new config workbook, triggering a rescan), but the
+sanctioned way to drive them is the existing FE flow — exposing them in a
+"legacy" CLI family would invite people to keep extending the surface
+instead of migrating off it.

package/dist/skills/dr-cli/reference/safety.md

@@ -0,0 +1,143 @@
+# Safety — confirm flow, prod gate, escalation
+
+## Two-step confirm (every `delete`, plus `templates set-field-type`)
+
+Running a gated command without a token fetches the target, prints its name +
+key attributes, and emits a short-lived confirmation token. Re-run with
+`--confirm-token <tok>` to actually perform the write.
+
+- The token is bound to `(resource, id, verb)`: a token for LUT 12 refuses
+  against function 12 — it catches ID typos, not just stray enter-hits.
+- Tokens expire after 10 minutes; the signing secret is per-machine and never
+  leaves the local machine.
+- Bulk operations bind the token to a hash of the change set (e.g.
+  `templates set-field-type --file`, `cash rules delete-all`), so editing the
+  file between plan and confirm invalidates the token.
+- The printed confirm command echoes the plan invocation's `--account`, so on
+  a keychain holding several identities for the server it can be pasted
+  verbatim — no need to re-add the flag by hand (gap #41).
+
+Gated commands include: `dashboards delete`, `datamappers delete`,
+`dynamic-ranges delete`, `extables delete`, `functions delete`, `lut delete`,
+`reports delete`, `storyboards delete`, `metrics delete`, `metrics categories
+delete`, `metrics dimensions delete`, `calcmodels delete|set-flow|recalculate`,
+`reconciliation filebox delete`, `integrations delete`, `integrations it
+delete`, `devices command-delete`, `validate onboarding session delete`,
+`widgets delete`, `cash rules delete|delete-all|reorder|update`,
+`cash hidden-rules upsert|delete`, `forecast` lock/unlock/default/delete/clone
+verbs, `workflow`/`mec workflow` create/update/activate/delete and friends,
+`collection-processes` create/mutate verbs, and the non-`delete` mutations
+`templates set-field-type`, `rescan table`, `features orgs add|remove`,
+`dashboards push`, `filebox push`, and `reconciliation accounts
+set-assignee|clear-assignee|set-due-date|sign|update-settings`. When
+in doubt, run the command without a token and read the plan output.
+
+## Prod write gate (when Claude drives the CLI)
+
+Reads never need confirmation. Gated **writes** fall into two tiers (full table:
+`src/commands/_prodGateTiers.ts`):
+
+- **Tier A — destructive / irreversible / org-wide.** On a prod tenant (`US`,
+  `US2`, `UK`, `CA`, `EU`, `DEMO` — DEMO is customer-facing) the binary requires a
+  live human to type a fresh challenge word in a desktop dialog / TTY (see
+  "Binary-enforced interactive gate" below). Relay the plan output (target name
+  + blast radius), get a clear in-chat "yes, do it", then re-invoke with
+  `--confirm-token <tok>`. That dialog IS the attentiveness check — do **not**
+  add your own word ritual in chat.
+- **Tier B — reversible / additive / low-blast.** No challenge word on any
+  server: token-only, fully scriptable, completable by an agent end-to-end.
+  Still relay the plan and get the user's in-chat "yes" before the execute step,
+  but it will not pop a dialog.
+- **Non-prod (`DEV`, `DEV-1`, `TEST`, `TEST-1`…`TEST-7`):** a plain `yes` is fine
+  for either tier — token only.
+
+**Tier A is the smaller set:** every `delete` (across all resources), plus
+`workflow`/`mec workflow` `archive` (and its `delete` alias), `process delete`,
+`step delete`, `task delete`; `forecast scenarios bulk-edit`; `cash rules
+delete-all`; `filebox archive` and `filebox data-query clear`;
+`multi-product org-products set`;
+`error-enrichments import` (replaces every rule on the server, zeroes all
+hits/feedback counters, and reassigns every rule id); and
+`dashboards push --override` / `filebox push --override`. `import` is **not** an
+edit or reconcile tool: changing a fleet of rules — including making one server
+match another — is a batch `create`/`update`, and `import` runs only when the
+user names `import` and confirms the loss of hits/thumbs analytics and the id
+reassignment. Never reach for it on your own initiative. `error-enrichments
+delete` takes several ids at once and spends **one** word gate on the whole
+batch, so the plan output — which lists every targeted rule with its hits and
+feedback — is the blast-radius check; read it per-rule, not as a count. Batch
+writes (`create`/`update`/`delete` with several targets) run sequentially and
+keep going after a per-item failure, then exit non-zero: the per-item summary
+table, not the exit code, is what says which ids actually landed. The two pushes
+**without** `--override` are Tier B — rolling a template out to child orgs is
+the workflow they exist for. One caveat on `filebox push`: create-new is the
+usual outcome but not guaranteed — if a destination already holds a filebox
+with the same alias and tags, the push adds a version to *that* filebox and it
+becomes the one served. The CLI cannot tell in advance and no word gate will
+stop it, so check the destination afterwards.
+Everything else gated is Tier B (all `create`/`update`/`reorder`/`set-*`/`lock`/
+`unlock` verbs, `templates set-field-type`, `rescan table` (a full historical
+rescan — expensive/high-blast but reversible, so token-only; the plan step shows
+the document + version counts), `metrics re-aggregate`, `metrics migrate` (the
+org-wide V1→V2 backfill — deletes nothing, but **overwrites**
+`category`/`time_aggregation` with the name-derived mapping, hand-set values
+included; per-metric before→after is in the response `details[]`. A
+request-level failure (500) rolls back everything; per-metric failures are
+non-fatal — a 200 can carry `metrics.errors[]` with the rest of the org
+committed, and under `--json` that warning is on **stderr**, not stdout.
+Always run `--dry-run` first, and check `metrics.errors[]` after the live
+run), `collection-processes`
+verbs, `cash rules update|reorder`, `spend-control contracts bulk-create`,
+`features orgs add|remove` (a delta over one `(org, flag)` boolean — each verb
+sets it, neither destroys state — so it is token-only even on prod, unlike
+`multi-product org-products set`, which replaces the whole entitlement set and
+stays Tier A. Running the opposite verb is **not** an undo: it sets membership to
+the opposite value, which restores the prior state only if that was the prior
+state, and the CLI never reads current membership. Check with `features orgs list
+<org_id>` before treating either verb as a revert), …).
+When unsure, run the plan step — a Tier-A prod execute in a non-interactive
+channel refuses and names the fix.
+
+For destructive operations, surface the blast radius first — e.g. "this removes
+the LUT that 4 functions depend on" — before running.
+
+### Binary-enforced interactive gate (Tier A only)
+
+The human check is enforced **in the binary** — not by prose an agent could
+skip or forget. When a valid `--confirm-token` is redeemed for a **Tier-A**
+action against a prod tenant (`US`, `US2`, `UK`, `CA`, `EU`, `DEMO` — plus,
+fail-closed, any server the CLI cannot positively classify as non-prod, and any
+action not positively classified as Tier B), the binary requires a live human:
+
+- **Interactive human** (desktop dialog on Windows/macOS/Linux, or a TTY
+  prompt): a fresh random word is shown *only in the dialog* and must be typed
+  back. Wrong word / cancel → the write does not happen.
+- **No interactive channel** (agent shell, pipe, headless/SSH): the command
+  refuses — it **exits non-zero** with an error naming the exact line to run
+  in a real terminal, so a script can't mistake the refusal for success.
+
+Practical consequence when you (Claude) drive the CLI: for a Tier-A prod write,
+run the **plan** step, relay it, get the user's in-chat yes, then run the
+**execute** step with the token yourself. On a desktop machine your subprocess
+runs inside the user's login session, so the dialog pops on *their screen* and
+they answer it there — the challenge word travels on a channel your toolchain
+can't read. In a headless/SSH context the execute step refuses instead, exits
+non-zero, and names the exact command for the user to run in a real terminal.
+Tier-B and non-prod writes are unaffected — token-only, fully scriptable.
+
+## Escalate / stop
+
+- A prod destructive without a clear in-chat "yes, do it" from the user.
+- A write that affects more than one customer or a shared fixture (e.g. editing
+  a data model multiple tenants depend on) — file a ticket instead.
+  - **Exception: `dashboards push` / `filebox push`.** Writing into other
+    organizations is the whole point of those two, so they are sanctioned rather
+    than escalated. What makes them safe is bounded: destinations are refused
+    unless they appear in `organizations push-targets` (the caller's own
+    inherited orgs — never an arbitrary tenant), the batch is capped at 50, and
+    the plan step names every destination as `name (id)` before the token is
+    issued. Relay that destination list to the user and get an explicit "yes"
+    naming the orgs — the multi-customer blast radius is real even though the
+    command is allowed.
+- The task needs a new subcommand / flag / API the CLI doesn't have — open a PR
+  against `Datarails/dr-cli`. Don't invent a command to fill the gap.