@oxy-hq/cli 0.1.0

package/skills/oxy-semantic-modeling/SKILL.md

@@ -0,0 +1,216 @@
+---
+name: oxy-semantic-modeling
+description: Use when writing, reviewing, or debugging an Oxy semantic model — `.view.yml` views, `.topic.yml` topics, measures, dimensions, entities, and the `meta:` freshness block — in a customer workspace, and when one misbehaves: a measure that vanishes after switching topics, "measure not found", a topic returning no rows or missing joins, or an agent reporting a partial day as a complete number. Carries the craft and the traps the reference docs do not.
+---
+
+# Oxy semantic modeling
+
+**The reference is upstream and maintained — read it rather than guessing:**
+<https://www.oxygen-hq.com/docs/guide/build/semantic-model/simple-model>
+(the section entry point; `views`, `entities`, `dimensions`, `measures`,
+`topics`, `modeling`, and `use-in-agents` sit beside it).
+
+That page owns the field lists. This skill deliberately does **not** restate
+them — a copied schema stays confidently wrong long after the real one moves.
+What follows is the craft and the traps it does not carry, with every example
+taken from Poke House's real 39 views and 23 topics.
+
+## View anatomy
+
+A view is one physical table plus the vocabulary an agent is allowed to use
+against it.
+
+```yaml
+name: sales_daily
+datasource: "clickhouse"
+table: "restaurant_analytics.restaurant_analytics___sales_daily_metrics"
+```
+
+**`entities` are the join graph, not decoration.** The `primary` entity names
+the grain of the row; `foreign` entities are the edges to other views; `parent:`
+states hierarchy (a sales day belongs to a restaurant).
+
+```yaml
+entities:
+  - name: sales_day
+    type: primary
+    key: sales_day_key
+    parent: restaurant
+  - name: restaurant
+    type: foreign
+    key: restaurant_id
+```
+
+**`key` names a dimension, not a column.** In `restaurants.view.yml` the entity
+`restaurant` has `key: restaurant_id`, and the `restaurant_id` *dimension* is
+`expr: guid` — the physical column is `guid`. So resolve a `key` against the
+view's `dimensions:` list, never against the table's columns; the reference's
+`entities` page carries the same warning.
+
+**`dimensions`** are what you slice by, **`measures`** what you aggregate. Both
+take `synonyms`; measures also take `filters` and `drivers`. House style keeps
+entity keys single — even a compound natural key is one pre-concatenated
+dimension (`sales_day_key`); no view uses the documented composite `keys:`.
+
+## The description is a contract with the agent, not a label
+
+`sales_daily`'s description, verbatim:
+
+> Daily sales metrics aggregated by restaurant and business date. Loaded several
+> times daily; the current business day is always intraday-partial - the prior
+> full day is the latest complete day.
+
+The second sentence is the whole point. Without it an agent asked "how are sales
+today?" reports a half-loaded partial day as a real number, confidently and with
+no warning — wrong in a way nobody can see downstream. Write descriptions that
+say when the data is complete and what it excludes, not what the table holds.
+
+## The `meta:` freshness block
+
+Four keys — `freshness_watermark_column`, `freshness_expected_cadence`,
+`freshness_complete_through`, `freshness_caveat` — that state a view's own lag
+characteristics so the agent can qualify an answer instead of guessing.
+
+**Only 11 of 39 views carry one.** That low number is the point: it is the most
+under-used high-value feature in a real model, and adding one is the cheapest
+quality win available on any view fed by a batch pipeline.
+
+- **It is undocumented.** Not one of the four keys appears anywhere in the docs,
+  and `views.mdx`'s own property table does not list `meta`. It is a working
+  project convention, not a schema feature you can look up. **Copy the block from
+  `sales_daily.view.yml`** — that is the canonical exemplar.
+- **Every value is wrapped as a single-element list** (`["prior full day
+  (America/Los_Angeles)"]`) even though each reads as a scalar. "Simplifying" it
+  to a bare string silently deviates from all 11 existing blocks.
+
+## Craft
+
+**`synonyms` are the natural-language surface.** Map both domain jargon and plain
+English onto one name; colliding common words across views is normal and wanted.
+
+```yaml
+  - name: total_net_sales
+    synonyms: ["net sales", "net revenue", "revenue", "sales"]
+  - name: sales_per_guest
+    synonyms: ["per guest average", "guest average", "PPA"]
+```
+
+**`samples` on enum-ish dimensions** tell the agent the valid values, so it
+filters on `"PAID"` instead of inventing `"paid"`. Give the *full* set, not a
+sample — `["OPEN", "PAID", "CLOSED"]`, `["negative", "neutral", "positive"]`.
+
+**Derived time dimensions so the agent never writes date arithmetic.** Ship
+`business_year`, `business_month`, `business_quarter`, `day_of_week`,
+`is_weekend` as dimensions of their own, each re-derived from the raw column
+rather than referencing the base date dimension:
+
+```yaml
+  - name: business_quarter
+    expr: "toQuarter(toDate(parseDateTimeBestEffort(toString(business_date))))"
+```
+
+**`drivers` must state a mechanism, not a vibe.** The quality bar, from
+`sales_daily`:
+
+```yaml
+  - name: total_net_sales
+    drivers:
+      - measure: sales_daily.discount_rate
+        direction: negative
+        strength: strong
+        confidence: high
+        description: "A larger share of gross sales given away as discounts lowers net sales. Unlike discount dollars, the rate does not move with volume."
+```
+
+Note what the `description` does: it names the causal path *and* says why the
+obvious alternative (discount dollars) was rejected. The weak examples in the
+corpus — in `quickbooks_pl.view.yml` — carry `direction`, `strength`,
+`confidence`, and a `lag`, but no `description` at all, so the mechanism is never
+stated and a reader cannot tell whether the edge was reasoned or guessed. A
+driver without a `description` is not finished. Only 8 of 39 views use
+`drivers`, and the field is absent from the semantic-model docs — see the traps.
+
+## Topics are question areas, not tables
+
+A topic is a `base_view` plus the views it may join to, and the filters that
+should always apply. That is the whole shape — all 23 real topics use only
+`name`, `description`, `views`, `base_view`, `default_filters`.
+
+```yaml
+name: orders
+base_view: orders
+views:
+  - orders
+  - order_checks
+  - order_selections
+  - restaurants
+  - dining_options
+default_filters:
+  - field: "is_voided"
+    eq:
+      value: false
+```
+
+Name topics after the questions people ask, and let `default_filters` carry the
+"obviously we don't count voided orders" rules so no one has to remember them.
+
+## Traps
+
+**The `airhouse_*` twins are a migration artifact, and they are not mirrors.**
+The ClickHouse → Airhouse migration is in flight, so **11 of the 39 views exist
+twice** (22 views, 11 twin pairs) — plus 3 further `airhouse_*` views with no
+ClickHouse counterpart at all, where discount- and payment-level detail lives
+only on the new side. Three consequences, in order of how much time they cost:
+
+1. **The twins have diverged.** `sales_daily` defines a `discount_rate` measure;
+   `airhouse_sales_daily` does not. Switch topics mid-conversation from one
+   family to the other and a query that worked seconds ago fails with "measure
+   not found", with nothing anywhere saying the two views were ever supposed to
+   match. Before assuming a measure exists on a twin, read the twin.
+2. **The two families cannot join to each other, and fail silently when you
+   try.** Every `airhouse_*` view prefixes its **foreign** entity names —
+   the edges — as `airhouse_restaurant`, `airhouse_order`, `airhouse_check`,
+   while its twin uses bare `restaurant`, `order`, `check`. Joins resolve by
+   matching entity *names*, so a topic mixing families does not error — it just
+   fails to auto-join. You get missing rows, not a config failure. No real topic
+   mixes them; keep it that way.
+
+   **The prefix is not universal, and the exception runs the other way.** The
+   three twin-less views from above leave their **primary** entity bare:
+   `airhouse_order_discounts` → `discount_application`,
+   `airhouse_order_payments` → `payment`, `airhouse_selection_discounts` →
+   `selection_discount_application`. Their foreign entities are still prefixed,
+   so rule 2 holds — but the latent failure inverts. A bare primary is exactly
+   what a ClickHouse-family view would declare, so if anyone ever adds a
+   `payment` or `discount_application` entity on the old side, those two views
+   start auto-joining *across* families rather than failing to join: wrong rows
+   silently, instead of missing rows silently. No such collision exists in the
+   corpus today (grep: each of the three names is declared in exactly one
+   view). Prefix the primary too on any new `airhouse_*` view.
+3. **Do not copy the pattern.** Duplicating a view to change backends is a
+   migration tactic with an end date, not a modelling technique.
+
+**Repeated defensive casting is a smell.** `toDate(parseDateTimeBestEffort(
+toString(business_date)))` appears in **6 derived dimensions of `sales_daily`** —
+the same three-deep cast chain re-typed six times because the underlying column
+is not a date. Fix the column type once, upstream in the pipeline, rather than in
+every `expr`. (Counting these by grep over-reports: a seventh occurrence is
+inside `measures:`, not `dimensions:`. The dimension count is 6.)
+
+**`drivers` and `parent:` are documented, but not where you would look.** Neither
+appears in the semantic-model pages — `drivers` is explained under
+<https://www.oxygen-hq.com/docs/guide/build/world-model/metric-tree> and
+`parent:` under <https://www.oxygen-hq.com/docs/guide/build/world-model>. Worse,
+the metric-tree page links back to `measures` claiming it defines the measures
+"and their drivers", which it does not. Read only the semantic-model section and
+you will conclude both fields do not exist and model without them.
+
+**View-qualified `{{ }}` references are the one-off, not the norm.** Across all
+39 views the `{{ view.measure }}` form appears in exactly **one expression** —
+the `discount_rate` measure at `sales_daily.view.yml:129`, which uses it twice
+in that one line (`{{ sales_daily.total_discounts }} / NULLIF({{
+sales_daily.total_gross_sales }}, 0)`). So a grep returns 2 hits from 1 site;
+neither number is "the norm". Every other `{{ }}` in the corpus is a bare,
+unqualified dimension name inside a measure's `filters:` — `{{is_voided}}`. For
+an ordinary same-view filter, write the bare form; copying the qualified one
+means copying the single outlier in the codebase.

package/template/.gitattributes

@@ -0,0 +1,2 @@
+# Generated index: never hand-merge. Regenerate with oxyc instead.
+memory/MEMORY.md merge=union linguist-generated=true

package/template/.github/scripts/ci-publish.sh

@@ -0,0 +1,77 @@
+#!/usr/bin/env bash
+# Does this repo publish its custom apps from CI, or does a human do it?
+#
+# OFF by default, and the default is the whole point. `customer-apps` — the
+# monorepo Oxy ships its own custom apps from — deleted its publish CI outright
+# and its engineers publish from their machines with `oxy login` and
+# `oxy publish`; its own docs say "there is no GitHub Actions / CI". A repo
+# scaffolded from this template therefore behaves the same way unless somebody
+# asks for CI publishing, rather than arriving demanding a long-lived token the
+# rest of the org has already decided it does not want.
+#
+# In its own file for the same reason publish-env.sh is: a `run:` block cannot
+# be executed anywhere but a runner, so anything left inline is unexecuted code
+# until the first real push. This is the switch the whole opt-in rests on, so it
+# is the last thing that should be unexecuted.
+#
+# THE SWITCH IS EXPLICIT, AND IT IS NOT THE TOKEN. Skipping the publish whenever
+# no OXY_TOKEN reached the job would have been one line, and it would have
+# destroyed the property publish.yaml is built around: that a publish into a
+# misconfigured environment is a loud credential failure rather than a quiet
+# success. Inferred from the token, "we do not publish from CI" and "somebody
+# forgot production's OXY_TOKEN" are the same observation — and the second one
+# then ships nothing, silently, for as long as nobody looks. Two causes need two
+# states, which is what this file is.
+#
+# A VARIABLE rather than a secret, for two reasons that both matter. It is read
+# in the `build` job — the only job that runs when publishing is off, and so the
+# only one that can say anything about it — and that job must reference no
+# `secrets.` at all: it executes the bundles' own postinstall scripts, and the
+# credential boundary in publish.yaml is enforced by a test that fails on any
+# secret reference there. The second reason is plainer: a switch whose entire
+# job is to tell "off on purpose" apart from "misconfigured" has to be legible,
+# in Settings and in a run log. A secret is neither.
+#
+# Contract:
+#   $1        the raw value, defaulting to $OXY_CI_PUBLISH — which publish.yaml
+#             fills from `vars.OXY_CI_PUBLISH`. Passed explicitly only by the
+#             tests.
+#   stdout    `on` or `off`, one line. Nothing else, ever: the workflow captures
+#             stdout into a job output that gates the publish job.
+#   stderr    when off, the ::notice:: that names the self-serve command and
+#             says how to turn CI publishing on.
+#   exit 0    for a value this file recognises, an absent one included.
+#   exit 1    for a value it does not.
+#
+# That last refusal is deliberate. `OXY_CI_PUBLISH=ture` cannot be read as
+# either answer, and both guesses are wrong in a way nobody would see: read as
+# off, the repo quietly stops publishing; read as on, it publishes when nobody
+# asked. It fails in the `build` job, which holds no credential, before a single
+# dependency is installed.
+
+set -euo pipefail
+
+raw="${1:-${OXY_CI_PUBLISH:-}}"
+
+# Case-folded through `tr` because bash 3.2 — which is what macOS ships and what
+# this repo's suite runs on — has no ${var,,}.
+value="$(printf '%s' "$raw" | tr '[:upper:]' '[:lower:]')"
+
+case "$value" in
+  # Absent is the default and the default is off. The explicit negatives are
+  # listed beside it for the person who writes `false` meaning it: a rule of
+  # "any non-empty value is on" would read that as a publish, which is the one
+  # misreading of a switch that costs something.
+  ''|false|no|off|0)
+    printf 'off\n'
+    printf '::notice::CI publishing is off in this repo, which is the default. This run built the app bundles and published nothing. Publishing here is self-serve: from an app directory under apps/, run "oxy login --env dev" once and then "oxy publish --env dev" (or --env production). To publish from CI instead, add a repository VARIABLE named OXY_CI_PUBLISH with the value true — Settings, then Secrets and variables, then Actions, then the Variables tab — and give each GitHub environment its own OXY_TOKEN.\n' >&2
+    ;;
+  true|yes|on|1)
+    printf 'on\n'
+    ;;
+  *)
+    printf '::error::OXY_CI_PUBLISH is set to "%s", which is neither on (true, yes, on, 1) nor off (false, no, off, 0, or the variable removed). Refusing to guess, because both guesses are silent: read as off this repo would stop publishing with nobody told, and read as on it would publish when nobody asked. Fix the value or delete the variable.\n' \
+      "$raw" >&2
+    exit 1
+    ;;
+esac

package/template/.github/scripts/discover-apps.sh

@@ -0,0 +1,175 @@
+#!/usr/bin/env bash
+# Which custom apps does this repo hold, and where does each one's build land?
+#
+# Split out of publish.yaml on purpose. GitHub Actions cannot be executed
+# locally, so anything left inline in a `run:` block is unexecuted code until
+# the first real push. This file is the part that CAN be run here, and it is
+# run — the same bytes, not a transcription of them.
+#
+# Contract:
+#   stdout  one line per app, "<app-dir><TAB><out-dir>", relative to the repo
+#           root, sorted. Empty when the repo has no apps.
+#   exit 0  including for zero apps. A freshly scaffolded repo has none, and
+#           its CI must be green on day one — a template that ships a red
+#           check teaches the team to stop reading checks.
+#   exit 1  only for a repo that HAS apps and cannot publish them: a manifest
+#           that will not parse, an app with no resolvable identity, or a
+#           missing lockfile.
+#   $GITHUB_OUTPUT gains `count=<n>` when that variable is set, so the
+#           workflow's skip condition and this script's answer are one value
+#           rather than two that can disagree.
+
+set -euo pipefail
+
+root="${1:-.}"
+
+emit_count() {
+  if [ -n "${GITHUB_OUTPUT:-}" ]; then
+    printf 'count=%s\n' "$1" >> "$GITHUB_OUTPUT"
+  fi
+}
+
+# `find` prints nothing and exits 0 when nothing matches, which is exactly
+# what a day-one repo produces. That is why discovery is a `find`, not a glob:
+# `for d in apps/*/` under `set -e` yields the literal string `apps/*/`, and a
+# legitimately-empty match then reads as either a phantom app or a hard
+# failure depending on what runs next. This project has been bitten by that
+# twice.
+#
+# -maxdepth 3 covers both layouts pnpm-workspace.yaml declares:
+#   apps/<app>/oxy-app.json         (depth 2)
+#   apps/<org>/<app>/oxy-app.json   (depth 3)
+# The prunes keep a dependency's own manifest, or a copy left inside a
+# previous build output, from being published as if it were one of ours.
+manifests=""
+unpruned=""
+if [ -d "$root/apps" ]; then
+  manifests="$(cd "$root" && find apps -maxdepth 3 \
+    \( -name node_modules -o -name out -o -name dist -o -name build \
+       -o -name .git -o -name .turbo \) -prune \
+    -o -type f -name oxy-app.json -print | LC_ALL=C sort)"
+  unpruned="$(cd "$root" && find apps -maxdepth 3 \
+    -type f -name oxy-app.json -print | LC_ALL=C sort)"
+fi
+
+# The prune above is right, but it is also SILENT, and silence is the wrong
+# half of it: an app whose directory is legitimately named `dist`, `out` or
+# `build` is dropped and the workflow then succeeds having published nothing.
+#
+# Warn about exactly that case and no other. A manifest under a pruned
+# directory that sits INSIDE a directory which is itself an app —
+# `apps/dashboard/out/oxy-app.json`, `apps/dashboard/node_modules/…` — is a
+# build artifact or a dependency's own manifest, correctly ignored, and
+# warning about it would be the noise that gets warnings ignored.
+if [ -n "$unpruned" ]; then
+  while IFS= read -r candidate; do
+    [ -n "$candidate" ] || continue
+    if printf '%s\n' "$manifests" | grep -qxF "$candidate"; then
+      continue
+    fi
+    skipped_dir="${candidate%/oxy-app.json}"
+    parent="${skipped_dir%/*}"
+    # Nested inside a real app: intended, stays quiet.
+    if printf '%s\n' "$manifests" | grep -qxF "$parent/oxy-app.json"; then
+      continue
+    fi
+    printf '::warning file=%s::%s was skipped: a directory named "%s" is treated as build output, not an app. Rename it if this really is an app — nothing here will be published.\n' \
+      "$candidate" "$skipped_dir" "${skipped_dir##*/}" >&2
+  done <<EOF
+$unpruned
+EOF
+fi
+
+if [ -z "$manifests" ]; then
+  printf 'publish: no custom apps under apps/ — nothing to build, nothing to publish.\n' >&2
+  emit_count 0
+  exit 0
+fi
+
+if ! command -v jq >/dev/null 2>&1; then
+  printf '::error::jq is not on this runner, so oxy-app.json cannot be read. GitHub'"'"'s ubuntu-latest image ships it; a self-hosted runner may not.\n' >&2
+  exit 1
+fi
+
+buffer="$(mktemp)"
+trap 'rm -f "$buffer"' EXIT
+
+bad=0
+count=0
+
+while IFS= read -r manifest; do
+  app_dir="${manifest%/oxy-app.json}"
+
+  if ! jq -e 'type == "object"' "$root/$manifest" >/dev/null 2>&1; then
+    printf '::error file=%s::%s is not a JSON object. oxy publish reads this file for the app identity and will not get past it.\n' \
+      "$manifest" "$manifest" >&2
+    bad=1
+    continue
+  fi
+
+  # `oxy publish` resolves the app slug as `--app`, then OXY_APP, then the
+  # manifest, then the `<app>` segment of an `apps/<org>/<app>/` path — that
+  # is the IMPLEMENTATION's order (publish.rs:779-785). Note that
+  # `oxy publish --help` states a different one, manifest before OXY_APP; the
+  # code is what runs, and its own comment agrees with the code. It makes no
+  # difference here either way: this workflow sets neither the flag nor the
+  # env var, and both readings end `manifest, then path` — the only two links
+  # this check depends on.
+  slug="$(jq -r '.slug // ""' "$root/$manifest")"
+  if [ -z "$slug" ] || [ "$slug" = "null" ]; then
+    printf '::error file=%s::%s has no "slug". That is the app'"'"'s identity on the platform and there is nowhere else to get it.\n' \
+      "$manifest" "$manifest" >&2
+    bad=1
+    continue
+  fi
+
+  # Same resolution chain for the org (publish.rs:773-778), with one
+  # difference that matters: the path fallback only fires for the nested
+  # `apps/<org>/<app>/` layout. In the flat `apps/<app>/` layout there is no
+  # `<org>` segment, so a manifest with no `orgSlug` leaves the org
+  # unresolvable — and `oxy publish` needs it to look the project up on the
+  # build-config endpoint.
+  org="$(jq -r '.orgSlug // ""' "$root/$manifest")"
+  nested=0
+  case "$app_dir" in
+    apps/*/*) nested=1 ;;
+  esac
+  if { [ -z "$org" ] || [ "$org" = "null" ]; } && [ "$nested" -eq 0 ]; then
+    printf '::error file=%s::%s has no "orgSlug", and %s is not an apps/<org>/<app>/ path for oxy publish to infer one from. Add "orgSlug" to the manifest.\n' \
+      "$manifest" "$manifest" "$app_dir" >&2
+    bad=1
+    continue
+  fi
+
+  # `build.outDir`, defaulting to `out` — the same default `oxy publish`
+  # applies. Guarded with a type check because a manifest whose `build` is a
+  # string (or a number) would make plain `.build.outDir` a jq error, and a jq
+  # error under `set -e` would abort the whole scan on one malformed file
+  # instead of reporting it.
+  out="$(jq -r 'if (.build | type) == "object" then (.build.outDir // "out") else "out" end' "$root/$manifest")"
+  if [ -z "$out" ] || [ "$out" = "null" ]; then
+    out="out"
+  fi
+
+  printf '%s\t%s\n' "$app_dir" "$out" >> "$buffer"
+  count=$((count + 1))
+done <<EOF
+$manifests
+EOF
+
+if [ "$bad" -ne 0 ]; then
+  exit 1
+fi
+
+# Reached only when the repo has at least one app, which is the only state in
+# which a lockfile is required. `pnpm install --frozen-lockfile` fails without
+# one, and it fails with a message about frozen lockfiles rather than about
+# the thing to do, so say the thing to do.
+if [ ! -f "$root/pnpm-lock.yaml" ]; then
+  printf '::error::this repo has %s custom app(s) but no pnpm-lock.yaml. "pnpm install --frozen-lockfile" cannot run without one: run "pnpm install" locally and commit the lockfile it writes.\n' \
+    "$count" >&2
+  exit 1
+fi
+
+emit_count "$count"
+cat "$buffer"

package/template/.github/scripts/publish-env.sh

@@ -0,0 +1,55 @@
+#!/usr/bin/env bash
+# Which oxy environment does this run publish to?
+#
+# One line of logic, in its own file for the same reason discover-apps.sh is:
+# a `run:` block cannot be executed anywhere but a runner, so anything left
+# inline is unexecuted code until the first real push. This is the mapping the
+# whole dev/prod split rests on, so it is the last thing that should be
+# unexecuted.
+#
+# It also has exactly one caller and one answer ON PURPOSE. The name printed
+# here is used TWICE by publish.yaml — as `oxy publish --env <name>` and as the
+# GitHub Actions `environment:` whose secrets that publish authenticates with —
+# and those two must never disagree. Two ternaries in the YAML would have been
+# shorter and would have drifted the first time one of them was edited; one
+# value, resolved once and read twice, cannot.
+#
+# Contract:
+#   $1        the trigger, defaulting to $GITHUB_EVENT_NAME. Passed explicitly
+#             only by the tests.
+#   stdout    the environment name on one line: `dev` or `production`.
+#   exit 0    only for a trigger this repo has a mapping for.
+#   exit 1    for anything else, INCLUDING an empty trigger.
+#
+# The refusal is the point. `oxy publish` defaults `--env` to **production**,
+# so a workflow that omits the flag ships a customer's live environment while
+# looking like it did nothing in particular — which is exactly what this repo's
+# CI did before this file existed. Every publish now names its environment out
+# loud, and a trigger nobody has thought about fails here rather than falling
+# through to the most dangerous of the two.
+
+set -euo pipefail
+
+trigger="${1:-${GITHUB_EVENT_NAME:-}}"
+
+case "$trigger" in
+  # A merge to main. Draft, to the dev workspace: main moving is not a decision
+  # to ship anything to a customer.
+  push)
+    printf 'dev\n'
+    ;;
+  # Someone stood at the Actions tab, picked a ref and pressed the button. That
+  # is the deliberate act, so that is the one that reaches production.
+  workflow_dispatch)
+    printf 'production\n'
+    ;;
+  '')
+    printf '::error::no trigger to map to an oxy environment: GITHUB_EVENT_NAME is empty and no argument was given.\n' >&2
+    exit 1
+    ;;
+  *)
+    printf '::error::this repo publishes on "push" and "workflow_dispatch" only, and has no oxy environment mapped for "%s". Add one to .github/scripts/publish-env.sh — deliberately, because the alternative is a trigger nobody reviewed publishing to production, which is what "oxy publish" does when nothing names an environment.\n' \
+      "$trigger" >&2
+    exit 1
+    ;;
+esac