chore(llm): sync .llm/exports from .cursor

Author: mitchdowney

.llm/exports/github-copilot/instructions/env-file-formatting.instructions.md

@@ -14,5 +14,6 @@ applyTo:
 - **Non-empty values**: Use double quotes (e.g. `API_PORT="3000"`).
 - **Empty/unset values**: No value after `=` (e.g. `OPTIONAL_VAR=`).
 - **Alignment**: When creating or editing generated env files, follow variable order and grouping from canonical templates/examples in [`infra/config/env-templates/`](../../infra/config/env-templates/) and app `.env.example` files. Only values may differ.
+- **Order (mixed files)**: When a file mixes server-side keys with `NEXT_PUBLIC_*`, put **all non-`NEXT_PUBLIC_*` assignments first**, blank line, then all `NEXT_PUBLIC_*`. See `.llm/exports/github-copilot/skills/env-file-formatting/SKILL.md`.
 
 Correct: `DATABASE_HOST="localhost"`, `EMPTY_VALUE=`. Incorrect: `DATABASE_HOST=localhost`, `EMPTY_VALUE=""`.

.llm/exports/github-copilot/instructions/no-runtime-change-schema-phase.instructions.md

@@ -0,0 +1,24 @@
+---
+description: "Converted from no-runtime-change-schema-phase.mdc"
+---
+# No Runtime Changes During Schema-Only Trust Phase
+
+When implementing a **schema-only** trust/entitlement foundation:
+
+## Required
+
+- Add forward-only migrations, constraints, and backfill.
+- Add ORM entities/relations and helper constants/types.
+- Update migration bundle wiring and expected migration markers.
+
+## Prohibited
+
+- Do not modify auth middleware behavior for trust/capability gating.
+- Do not add route/controller allow-deny checks.
+- Do not expose trust settings in API responses.
+- Do not change web/management-web blocked-action behavior.
+
+## Intent
+
+Schema-only phases prepare data-model infrastructure only. Runtime behavior belongs to a separate
+implementation phase with dedicated integration/E2E coverage.

.llm/exports/github-copilot/skills/argocd-gitops-push/SKILL.md

@@ -10,33 +10,36 @@ description: When adding or changing files under infra/k8s/ or sync targets for
 
 When adding or changing files under:
 
-- `infra/k8s/` (local, base, or app-of-apps manifests and referenced resources),
-- Or any path that is part of an Argo CD Application source (e.g. `infra/k8s/local/apps`, `infra/k8s/local/stack`, `infra/k8s/base/stack`, source under base, and files referenced by those via Kustomize),
-- Or **canonical linear migration SQL** under `infra/k8s/base/ops/source/database/linear-migrations/{app,management}/` (versioned chain applied by the linear migration runner),
-- Or **ops** manifests under `infra/k8s/base/ops/` (Kustomize bundles: migration CronJob SQL, scripts mounted into jobs, and related `kustomization.yaml` entries that must stay in sync with on-disk files).
+- **`infra/k8s/base/`** – reusable Kustomize bases per component (referenced by alpha overlays and/or your GitOps repo),
+- **`infra/k8s/alpha/`** – in-repo alpha app-of-apps and child overlays,
+- **`infra/k8s/argocd/`** – optional project manifests committed here,
+- Any path that is part of an **Argo CD Application** source in **your GitOps repository** (paths vary by installation),
+- **Canonical linear migration SQL** under `infra/k8s/base/ops/source/database/linear-migrations/{app,management}/`,
+- **Ops** manifests under `infra/k8s/base/ops/` (migration CronJobs, mounted scripts, `kustomization.yaml` entries).
 
 ## What Argo CD syncs
 
-- The local app points at repo path `infra/k8s/local/apps` (see `infra/k8s/local-application.yaml`), which references `infra/k8s/local/stack` and the base stack.
-- The alpha app-of-apps root points at repo path `infra/k8s/alpha/apps` (see `infra/k8s/alpha-application.yaml`), which references `infra/k8s/alpha/<component>/` overlays.
-- Only the **remote** Git repo at the configured revision (e.g. `develop`) is used; the agent does not push. The user must push for Argo CD to see changes.
+- **Alpha:** Root **`infra/k8s/alpha-application.yaml`** (when applied) points at **`infra/k8s/alpha/apps`**, which references **`infra/k8s/alpha/<component>/`** overlays.
+- **Remote environments:** Application CRs usually live in your **GitOps repo** and reference paths/branches you configure (see [docs/development/k8s/REMOTE-K8S-GITOPS.md](../../../docs/development/k8s/REMOTE-K8S-GITOPS.md)).
+- Only the **remote** Git revision Argo CD tracks is authoritative; the agent does not push.
 
 ## When a push is required
 
-Any change to files under those paths (or to canonical sources that get copied into them) means the cluster will not reflect the change until the user pushes to the branch Argo CD tracks.
+Any change to synced paths (or canonical sources copied into them) is invisible to the cluster until those commits are on the branch Argo CD watches (**often `develop` / `main` on the GitOps repo**).
 
 ## Response requirement
 
-When your file-modifying work touches any of these paths, add a short **Push to Git** note in the response (e.g. before or after the verification block):
+When file-modifying work touches **`infra/k8s/`** or migration SQL under **`infra/k8s/base/ops/`**, add a short **Push to Git** note:
 
-**Push to Git:** This change affects Argo CD–synced manifests. Push to the branch Argo CD tracks (e.g. `develop`) for the cluster to sync.
+**Push to Git:** This change affects Argo CD–synced manifests. Push to the branch Argo CD tracks so the cluster can sync.
 
 ## Version updates (GitOps)
 
-- **Manifest changes** (image tags, env, resources, new deployments): Updating the manifest is the change; push is required for Argo CD (covered by the response reminder above).
-- **npm/package versions:** Follow the existing AGENTS.md Dependencies section; no separate version rule for GitOps.
+- **Manifest changes** (image tags, env, resources): push so Argo CD picks them up.
+- **npm/package versions:** Follow AGENTS.md Dependencies; no separate GitOps-only rule.
 
 ## See also
 
-- [infra/k8s/INFRA-K8S.md](infra/k8s/INFRA-K8S.md) – k8s layout and local app-of-apps.
-- [docs/development/k8s/K3D-ARGOCD-LOCAL.md](docs/development/k8s/K3D-ARGOCD-LOCAL.md) – Local k3d + Argo CD setup.
+- [infra/k8s/INFRA-K8S.md](../../../infra/k8s/INFRA-K8S.md) – layout and consumption.
+- [docs/development/k8s/REMOTE-K8S-GITOPS.md](../../../docs/development/k8s/REMOTE-K8S-GITOPS.md) – remote cluster workflow.
+- [docs/development/k8s/K3D-ARGOCD-LOCAL.md](../../../docs/development/k8s/K3D-ARGOCD-LOCAL.md) – stub (local k3d removed).

.llm/exports/github-copilot/skills/entitlement-gating-rollout/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: entitlement-gating-rollout
+description: Roll out trust/entitlement behavior after schema foundations. Use when introducing capability checks, resolver logic, and deny contracts.
+---
+
+
+# Entitlement Gating Rollout
+
+Use this skill for the post-foundation runtime phase.
+
+## Rollout order
+
+1. Add centralized entitlement resolver logic.
+2. Add trust-tier default policy (env/config driven).
+3. Apply per-user override precedence.
+4. Introduce capability checks in auth/controller boundaries.
+5. Map deny outcomes to stable API payload contracts.
+
+## API deny contract
+
+- Include machine-readable `code`.
+- Include stable `i18nKey`.
+- Include action path (for example renew/upgrade) when applicable.
+
+## Coverage checklist
+
+- All protected write/update actions use capability checks.
+- Stats/notifications behavior follows entitlement policy.
+- Management/admin edit surfaces can control overrides.
+- Web and management-web map denial payloads consistently.
+
+## Testing expectations
+
+- Integration tests for allow/deny and override precedence.
+- E2E tests for blocked UX and admin override effects.

.llm/exports/github-copilot/skills/env-file-formatting/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: env-file-formatting
+description: Env file value formatting and NEXT_PUBLIC ordering. Use when adding or editing .env,
+  .env.example, or any *.env template in the repo.
+---
+
+
+# Env file formatting
+
+## When to use
+
+When adding or editing `.env`, `.env.example`, or any `*.env` template (including
+`infra/config/env-templates/*.env.example`, `infra/k8s/**/source/*.env`, and `dev/env-overrides/local/*.env.example`).
+
+## Rules
+
+- **Non-empty values**: Double quotes. **Empty/unset**: no value after `=` (see `.llm/exports/github-copilot/instructions/env-file-formatting.instructions.md`).
+- **K8s `source/*.env` comments**: at most **one** env var name per `#` line.
+
+## Variable order when mixing server and `NEXT_PUBLIC_*`
+
+If a file defines both keys that are **not** `NEXT_PUBLIC_*` (e.g. `API_PORT`, `READINESS_*`,
+`NODE_ENV`, `RUNTIME_CONFIG_*`) **and** any `NEXT_PUBLIC_*`:
+
+1. All non-`NEXT_PUBLIC_*` assignments first (group with section comments as needed).
+2. Blank line.
+3. All `NEXT_PUBLIC_*` keys.
+
+Files that are only `NEXT_PUBLIC_*` or only server keys need no extra ordering.
+
+## References
+
+- [.llm/exports/github-copilot/instructions/env-file-formatting.instructions.md](../../.llm/exports/github-copilot/instructions/env-file-formatting.instructions.md)
+- [AGENTS.md](../../AGENTS.md) — env templates and local overrides

.llm/exports/github-copilot/skills/linear-baseline-gz-sync/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: linear-baseline-gz-sync
+description: Regenerate committed linear baseline .sql.gz artifacts whenever app/management linear SQL migrations change.
+---
+
+
+# Linear Baseline GZ Sync (Metaboost)
+
+Use this skill whenever you add, remove, or edit files under:
+
+- `infra/k8s/base/ops/source/database/linear-migrations/app/**`
+- `infra/k8s/base/ops/source/database/linear-migrations/management/**`
+- `scripts/database/generate-linear-baseline.sh`
+
+## Goal
+
+Keep committed bootstrap baseline archives aligned with the canonical forward-only SQL chain.
+
+## Required actions
+
+1. Regenerate baseline archives from repo root:
+   - `bash scripts/database/generate-linear-baseline.sh`
+2. Verify generated output is current:
+   - `bash scripts/database/verify-linear-baseline.sh`
+3. Commit changed generated artifacts when they differ:
+   - `infra/k8s/base/db/source/bootstrap/0003a_app_linear_baseline.sql.gz`
+   - `infra/k8s/base/db/source/bootstrap/0003b_management_linear_baseline.sql.gz`
+
+## Related files to keep aligned
+
+- `infra/k8s/base/ops/kustomization.yaml` (migration file wiring)
+- `infra/k8s/base/api/source/api.env` and `infra/k8s/base/management-api/source/management-api.env` (expected migration markers)
+
+## Notes
+
+- Do not hand-edit `.sql.gz` archives.
+- Generated baseline artifacts are source-controlled and must be updated in the same PR as migration changes.

.llm/exports/github-copilot/skills/linear-db-migrations/SKILL.md

@@ -10,25 +10,25 @@ version: 1.0.0
 ## When to use
 
 - Adding or changing files under `infra/k8s/base/db/source/`, `infra/k8s/base/ops/`, or `scripts/database/`.
-- Wiring DB credentials in Compose, k3d, or K8s manifests, or in env templates/examples.
+- Wiring DB credentials in Compose, Kubernetes manifests, or env templates/examples.
 
 ## Single source of truth
 
 - **Canonical forward-only SQL:** `infra/k8s/base/ops/source/database/linear-migrations/app/` and `infra/k8s/base/ops/source/database/linear-migrations/management/` (ordered `0001_*.sql`, ...).
-- **Bootstrap init (`docker-entrypoint-initdb.d`):** `infra/k8s/base/db/source/bootstrap/` — shell steps **`0001`** / **`0002`**, generated **`0003_linear_baseline.sql.gz`** and **`0004_seed_linear_migration_history.sql`**, then **`0006_management_grants.sh`**.
+- **Bootstrap init (`docker-entrypoint-initdb.d`):** `infra/k8s/base/db/source/bootstrap/` — shell steps **`0001`** / **`0002`**, then **`0003_apply_linear_baselines.sh`** with generated **`0003a_app_linear_baseline.sql.gz`** / **`0003b_management_linear_baseline.sql.gz`**.
 - **Generated bootstrap artifacts:**
-  - `infra/k8s/base/db/source/bootstrap/0003_linear_baseline.sql.gz`
-  - `infra/k8s/base/db/source/bootstrap/0004_seed_linear_migration_history.sql`
+  - `infra/k8s/base/db/source/bootstrap/0003a_app_linear_baseline.sql.gz`
+  - `infra/k8s/base/db/source/bootstrap/0003b_management_linear_baseline.sql.gz`
   - Generated by scripts under `scripts/database/`; do not hand-edit.
 
 ## Runner and validation
 
 - Apply migrations: `bash scripts/database/run-linear-migrations.sh --database app|management` (always pass `--database`; there is no default).
-- K8s wrapper: `bash scripts/database/run-linear-migrations-k8s.sh` (same requirement).
+- **Credentials:** **app** migrations use `DB_APP_MIGRATOR_USER`, `DB_APP_MIGRATOR_PASSWORD`, `DB_APP_NAME`, `DB_HOST`, and `DB_PORT`. **Management** migrations use `DB_MANAGEMENT_MIGRATOR_USER`, `DB_MANAGEMENT_MIGRATOR_PASSWORD`, `DB_MANAGEMENT_NAME`, `DB_HOST`, and `DB_PORT`. Optional: `infra/config/local/db.env` when keys are unset before sourcing.
+- K8s wrapper: `bash scripts/database/run-linear-migrations-k8s.sh` (`--database` required); validates the same keys from Secrets.
 - Validate: `bash scripts/database/validate-linear-migrations.sh` (and `--check-db` to compare on-disk checksums to `linear_migration_history` when a DB is available).
 - Regenerate baseline artifacts:
   - `bash scripts/database/generate-linear-baseline.sh`
-  - `bash scripts/database/generate-linear-migration-history-seed.sh`
 - Verify generated artifacts are committed and up to date:
   - `bash scripts/database/verify-linear-baseline.sh`
 - The migration runner **creates** the `linear_migration_history` table if missing; do not rely on a dedicated SQL file for that.
@@ -40,13 +40,13 @@ version: 1.0.0
 
 ## Environment keys (admin vs image)
 
-- **Authoritative in secrets and generated env:** `DB_APP_ADMIN_USER` / `DB_APP_ADMIN_PASSWORD`, `DB_MANAGEMENT_ADMIN_USER` / `DB_MANAGEMENT_ADMIN_PASSWORD`, plus read-only and read-write keys and `DB_APP_NAME` / `DB_MANAGEMENT_NAME` (see `infra/config/env-templates/db.env.example` and local `infra/config/local/db.env` after `scripts/local-env/setup.sh`).
-- The **postgres** container image still reads `POSTGRES_USER` / `POSTGRES_PASSWORD` / `POSTGRES_DB` at runtime—**map** those from the `DB_*_ADMIN_*` and `DB_APP_NAME` keys in Compose or Deployment `env`, not the reverse.
+- **Authoritative in secrets and generated env:** owner keys (`DB_APP_OWNER_*`, `DB_MANAGEMENT_OWNER_*`) for bootstrap, migrator keys (`DB_APP_MIGRATOR_*`, `DB_MANAGEMENT_MIGRATOR_*`) for linear migrations, plus read-write and read keys and `DB_APP_NAME` / `DB_MANAGEMENT_NAME` (see `infra/config/env-templates/db.env.example` and local `infra/config/local/db.env` after `scripts/local-env/setup.sh`).
+- The **postgres** container image still reads `POSTGRES_USER` / `POSTGRES_PASSWORD` / `POSTGRES_DB` at runtime—**map** those from `DB_APP_OWNER_USER` / `DB_APP_OWNER_PASSWORD` and `DB_APP_NAME` in Compose or Deployment `env`, not the reverse.
 
 ## Cross-repo invariants
 
 - Canonical forward-only trees under `infra/k8s/base/ops/source/database/linear-migrations/`.
-- Generated bootstrap baseline artifacts `0003` and `0004` are machine-derived and committed.
+- Generated bootstrap baseline artifacts `0003a` and `0003b` are machine-derived and committed.
 - Same npm script naming model in root `package.json` (`db:migrate:linear:*`, `db:validate:linear`, etc.). Product-specific naming differences are expected.
 
 ## Documentation

.llm/exports/github-copilot/skills/local-docker-env-alignment/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: local-docker-env-alignment
+description: When adding or changing preconditions, cleanup steps, or env usage for local Docker Compose, keep behavior aligned with shared infra/config/local/*.env and documented teardown flows.
+---
+
+
+# Local Docker Compose env alignment
+
+## When to use
+
+When you:
+
+- Add or change **`make`** targets that touch **`infra/config/local/*.env`** or local containers (`metaboost_local_*`),
+- Add guards to **`local_env_clean`** / **`local_clean`**, or
+- Document local env setup / teardown.
+
+Metaboost does **not** ship an in-repo local Kubernetes (k3d) path; cluster validation is **remote GitOps**.
+
+## Do
+
+- Keep **`local_env_clean`** blocked while **Docker Compose** Metaboost local containers are running (`make local_down` first).
+- Keep **`local_clean`** as full teardown: **`local_down`**, **`local_down_volumes`**, **`test_clean`** (and any other documented test/E2E containers).
+- Document that **`make local_env_setup`** and Compose share **`infra/config/local/*.env`** where applicable.
+
+## Don't
+
+- Reference k3d or `make local_k3d_*` (removed).
+
+## Reference targets
+
+- **`local_env_clean`**: Aborts if `metaboost_local_*` containers are running.
+- **`local_clean`**: Docker + volumes + test stack teardown.

.llm/exports/github-copilot/skills/membership-expiry-ux-contract/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: membership-expiry-ux-contract
+description: Keep expiry-related API and UX behavior consistent. Use when implementing reduced-functionality states, blocked-action modals, and renewal/upgrade navigation.
+---
+
+
+# Expiry UX Contract
+
+Use this skill whenever account expiry or eligibility loss affects user actions.
+
+## API contract
+
+- Return non-alarming expiry responses.
+- Include `code` + `i18nKey` for deterministic UI mapping.
+- Include action path when users can remediate.
+
+## UI contract
+
+- Persistent reminder banner for reduced functionality state.
+- Blocked-action modal with:
+  - dismiss
+  - direct remediation action (renew/upgrade/contact)
+- Shared mapping layer for denial code -> UI message/action.
+
+## Content principles
+
+- Be clear and actionable.
+- Avoid alarming error language.
+- Explain reduced behavior succinctly.
+
+## Consistency checks
+
+- All protected surfaces consume the same deny contract.
+- i18n keys exist for surfaced copy.
+- Modal and banner behavior do not conflict.

.llm/exports/github-copilot/skills/migration-readiness-marker-sync/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: migration-readiness-marker-sync
+description: Keep K8s readiness migration marker env vars aligned with latest linear SQL migrations. Use when adding/changing linear migrations or readiness init checks.
+---
+
+
+# Migration Readiness Marker Sync (Metaboost)
+
+Use this skill whenever you touch:
+
+- `infra/k8s/base/ops/source/database/linear-migrations/**`
+- API or management-api migration wait initContainers
+- API or management-api K8s `source/*.env` files containing readiness migration marker vars
+
+## Goal
+
+Ensure startup readiness gates verify the correct latest migration marker for each DB domain.
+
+## Required alignment
+
+When new latest migrations are added:
+
+1. Update marker env defaults:
+   - `infra/k8s/base/api/source/api.env`:
+     - `API_EXPECTED_MIGRATION_FILENAME`
+   - `infra/k8s/base/management-api/source/management-api.env`:
+     - `MANAGEMENT_API_EXPECTED_MIGRATION_FILENAME`
+2. Verify initContainer SQL checks in:
+   - `infra/k8s/base/api/deployment.yaml`
+   - `infra/k8s/base/management-api/deployment.yaml`
+     They must read marker env vars and not stale hardcoded filenames.
+3. Keep Kustomize configMap wiring in sync so the updated values reach pods.
+
+## Migration source of truth
+
+Use latest SQL filenames under:
+
+- `infra/k8s/base/ops/source/database/linear-migrations/app/`
+- `infra/k8s/base/ops/source/database/linear-migrations/management/`
+
+If a migration becomes a startup prerequisite, update marker env values in the same PR.
+
+## Verification checklist
+
+- `kustomize build --load-restrictor LoadRestrictionsNone infra/k8s/base/api`
+- `kustomize build --load-restrictor LoadRestrictionsNone infra/k8s/base/management-api`
+- Confirm rendered initContainer SQL checks reference updated marker env vars.