@rtrentjones/greenlight 0.2.4

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 RTrentJones
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/assets/skills/deploy-verify-promote/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: deploy-verify-promote
+description: Ship a change through Greenlight's loop — deploy to preview/beta, verify with the shared harness, then gated-promote develop→main to prod. Use when making a change to a Greenlight tool or the blog and you want it shipped with confidence, or when explicitly asked to deploy/verify/promote.
+---
+
+# deploy-verify-promote
+
+The execution discipline for changing a Greenlight tool or the blog. The verify
+harness and promote guard are the **same code CI runs**, so passing locally means
+passing in CI. This is what lets a change (or a long string of changes) be shipped
+with objective confidence rather than vibes.
+
+## Input
+
+- `<name>` — a manifest entry: `blog`, or a tool name from `greenlight.config.ts`.
+
+## Deterministic URL scheme (never scrape deploy logs)
+
+| Subject | prod | beta |
+|---|---|---|
+| tool | `https://<name>.<domain>` | `https://beta.<name>.<domain>` |
+| blog (apex) | `https://<domain>` | `https://beta.<domain>` |
+| mcp connect | *(tool url)* `+ /mcp` | same `+ /mcp` |
+
+`preview` is per-target and comes from the adapter's `deploy()` result. Everything
+else is computed by `resolveUrl` in `@rtrentjones/greenlight-shared`.
+
+## Procedure
+
+1. **Branch** — `git checkout -b <type>/<slug>` (e.g. `post/hello`, `fix/mcp-auth`).
+2. **Make the change.**
+3. **Preview** — push; the target's git integration produces a preview deploy. Verify it.
+   - Local/CI: `runLoop` (build → deploy → verify) from `@rtrentjones/greenlight-loop`.
+   - Standalone / local server: `pnpm greenlight verify <name> --url <preview-or-localhost-url>`.
+4. **Beta** — merge to `develop` → beta deploy. `pnpm greenlight verify <name> --env beta`.
+   Mode is chosen by lane: `api`/`playwright` for web, `mcp` for MCP servers.
+5. **Promote** — `pnpm greenlight promote <name>`. Checks the fast-forward guard
+   (`develop → main`). If it refuses (diverged `main`), reconcile and retry — never force-push.
+6. **Prod** — after promote, `pnpm greenlight verify <name> --env prod`.
+
+## Rules
+
+- `verify` exits non-zero if any check fails; the report lists each. **Never promote a
+  tool whose beta verify is failing.**
+- Connect URL for MCP tools is the tool URL + `/mcp`; `verify` handles this by lane.
+- Real per-target deploys are wired in phases (greenlight-v1.md §16); the loop, verify,
+  and promote guard are stable now.
+
+## Cross-repo note
+
+In standalone repos (BAMCP, ejected tools) this skill is delivered by the **Greenlight
+Claude Code plugin** (Phase 7), and the mechanics by the `@rtrentjones/greenlight*` npm
+deps; the per-repo parameters come from that repo's `greenlight.config.ts`.

package/assets/skills/provider-cloudflare/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: provider-cloudflare
+description: How Cloudflare works in a Greenlight setup — the zone/DNS provider for every tool, Workers as the keepalive/blog target, token scoping (Workers Scripts:Edit + Zone DNS:Edit), and the Cloudflare MCP. Use when wiring DNS, the keepalive worker, a workers-target tool, or debugging a Cloudflare apply/token.
+---
+
+# provider-cloudflare
+
+Cloudflare is the **always-on** provider in Greenlight: it owns the DNS zone for the
+domain (every tool's `<name>.<domain>` CNAME), hosts the **keepalive** Worker (a Cron
+Trigger, immune to repo-inactivity disable), and is the `target: workers` runtime for the
+blog and throwaway MCP dev targets.
+
+## Token — `CLOUDFLARE_API_TOKEN`
+
+One token, **two scopes** (the trap that took down a live apply):
+- **Account · Workers Scripts · Edit** — deploy the keepalive worker / workers-target tools.
+- **Zone · DNS · Edit** — the subdomain CNAMEs.
+- **Account · Account Settings · Read** — read account id.
+
+Create at dash → My Profile → API Tokens → Custom Token. Store in `.greenlight/secrets.env`
+(gitignored) and push to GitHub Actions with `greenlight secrets sync`. `greenlight add`
+verifies it against `/user/tokens/verify` (status must be `active`) before you commit.
+
+## Terraform modules
+
+- `infra/modules/tool` — the subdomain DNS record. `proxied = target != "vercel"` (Vercel
+  needs an unproxied CNAME to `cname.vercel-dns.com`; everything else is proxied).
+- `infra/modules/keepalive` — `cloudflare_workers_script` + `cloudflare_workers_cron_trigger`,
+  self-contained (ships its own bundled `worker.js`). One worker aggregates all targets via
+  `targets_json`; do **not** emit a worker per tool. Needs a workers.dev subdomain registered
+  on the account once (error 10063 if missing).
+
+## MCP
+
+`.mcp.json` wires `cloudflare` (Workers/DNS/R2/KV/D1/builds/observability) + `cloudflare-docs`.
+Run `/mcp` to authenticate. For richer help: the `cloudflare@cloudflare` plugin skill.
+
+## Gotchas
+- A DNS record for the apex managed by **wrangler** (Workers custom domain) collides with a
+  Terraform `cloudflare_dns_record` for the same name — pick one owner per record.
+- The `observability` block on `cloudflare_workers_script` has a provider bug
+  (propagation_policy conversion error) — leave it off.

package/assets/skills/provider-github/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: provider-github
+description: How GitHub works in a Greenlight setup — secrets sync target (Actions secrets/environments), the repo/branch/protection Terraform module, the develop→main flow, and OIDC-over-PAT preference. Use when syncing tokens, wiring branch protection/environments, or debugging gh/secrets/CI auth.
+---
+
+# provider-github
+
+GitHub is the **always-on** control plane: it holds the Actions **secrets** (provider tokens),
+the **environments** (beta/prod), branch protection, and runs the deploy/promote/infra
+workflows. The `develop → main` flow is standardized (PR → preview, `develop` → beta, `main`
+→ prod; promote is a gated fast-forward).
+
+## Token — `GITHUB_TOKEN` (usually you don't set one)
+
+- In **CI**, Actions provides `github.token` automatically — the infra.yml maps it to the
+  `github` provider. No PAT needed for single-repo infra.
+- For **cross-repo** ops (managing another repo's settings, syncing secrets to a tool repo),
+  use a fine-grained **PAT** with the minimal scopes (e.g. `Secrets: write`, `Administration`
+  for protection). Prefer **GitHub OIDC → cloud** over long-lived cloud tokens where supported.
+
+## Secrets sync
+
+`greenlight secrets sync [--repo o/r] [--env <env>]` pushes `.greenlight/secrets.env` to the
+repo's Actions secrets via `gh` (values piped on stdin — never in argv or logs). Run
+`gh auth login` first. This is the "init writes to provider stores" piece.
+
+## Terraform module — `infra/modules/repo`
+
+Branches + protection + required checks (+ optional environments via the `tool` module's
+`manage_github_environments`). For an **external** tool (code in its own repo), set
+`manage_github_environments = false` so the wrapper's CI stays single-repo (no PAT needed).
+
+## Gotcha
+Direct pushes/merges to a protected `main` are blocked — use `gh pr create` + merge, or the
+gated `greenlight promote` fast-forward. Keep to `develop` (not `development`) for the branch.

package/assets/skills/provider-hcp/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: provider-hcp
+description: How HCP Terraform works in a Greenlight setup — the remote-state backend (free tier, no credit card), local execution mode (HCP stores state + locks; runs use local/CI creds), the cloud{} block, and TF_API_TOKEN auth. Use when setting up remote state, debugging a backend/init/locking issue, or CI apply-on-push.
+---
+
+# provider-hcp
+
+HCP Terraform (app.terraform.io) is the **remote-state backend** for the wrapper's infra —
+free tier, **no credit card**. It replaces local state so CI can `terraform apply` on push
+with state locking (no two applies racing).
+
+## Execution mode — **Local**, deliberately
+
+The workspace is set to **Local execution mode**: HCP **stores state + does locking only**;
+`terraform` runs here / in CI with **our own provider creds** (Cloudflare/Vercel/Supabase
+tokens from GitHub Actions secrets). This avoids uploading every provider token to HCP.
+
+## Token — `TF_API_TOKEN`
+
+HCP → Account Settings → Tokens (a **user** API token). In CI it maps to the backend-auth env
+var **`TF_TOKEN_app_terraform_io`** (the infra.yml does this mapping). `greenlight add`
+verifies it against `/api/v2/organizations` (HTTP 200).
+
+## The `cloud{}` block
+
+```hcl
+terraform {
+  cloud {
+    organization = "YOUR_ORG"
+    workspaces { name = "your-domain-with-dashes" }
+  }
+}
+```
+
+Migrate local → HCP with a plain `terraform init` (answer `yes` to copy state). The
+`-migrate-state` / `-force-copy` flags are **rejected** for the cloud backend — don't pass them.
+
+## CI apply-on-push
+
+`infra.yml` (on push to `main`, paths `infra/**`): map GH secrets → `TF_TOKEN_app_terraform_io`
++ the provider tokens + `TF_VAR_*`, then setup-terraform (`terraform_wrapper: false`) → init →
+plan -out → apply. This is the deploy half — the CLI only edits the `.tf`; CI applies.
+
+## Alternatives
+See `docs/terraform-state-r2.md` for the full backend chooser (HCP no-CC · OCI S3-compat ·
+R2 card-required · AWS · local).

package/assets/skills/provider-oci/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: provider-oci
+description: How Oracle Cloud (OCI) works in a Greenlight setup — the `target: oci` runtime for stateful MCP servers (BAMCP) on a free-tier Ampere A1 Container Instance, the provider-agnostic build-via-GitHub→GHCR model, Greenlight-owned compute + tunnel Terraform, the OCI token CLI, deploy = restart, and the Always-Free idle-reclaim trap (PAYG, manual). Use when wiring/debugging an oci-target tool.
+---
+
+# provider-oci
+
+OCI is the `target: oci` runtime for **stateful** services that don't fit serverless — the
+canonical case is **BAMCP** (a stateful MCP server). The split: **the tool is provider-agnostic
+and just builds a container via GitHub; Greenlight owns the OCI infra** (compute + tunnel + DNS),
+configured in the wrapper.
+
+## Free tier — A1 Container Instance + GHCR
+
+The Always-Free path is an **OCI Container Instance** on **Ampere A1** (the A1 allotment — 2 OCPU
+/ 12 GB as of 2026-06-15 — is shared across VM / Bare-Metal / Container-Instances). No VM to
+provision, no cloud-init, no SSH. The image comes from **GHCR** (free); **OCI's own registry
+(OCIR) is paid** — that was the trap in the old BAMCP pipeline. The container instance runs the
+tool container + a **cloudflared sidecar** (shared netns → localhost), exposed at `<name>.<domain>`.
+
+## Provider-agnostic tool → GHCR
+
+The tool repo (BAMCP) has ONE job: a GitHub Actions workflow that **builds + pushes the container
+to GHCR**. No OCI, no SSH, no deploy logic — portable to any provider's infra.
+
+## Greenlight OCI infra (Terraform, in the wrapper)
+
+`greenlight add/adopt` emits, per oci tool:
+- **`oci-container-instance`** module — the container instance (tool image from GHCR + cloudflared
+  sidecar with the tunnel token), `CI.Standard.A1.Flex` within the free allotment, restart ALWAYS.
+- **`tunnel`** module — cloudflared tunnel + ingress `<name>.<domain> → http://localhost:8000` + token.
+- **`tool`** DNS module — CNAME → the tunnel.
+The `oci` provider (auth below) is added to `infra/main.tf`.
+
+## OCI token CLI
+
+`greenlight add`/`init` gather the OCI creds into `.greenlight/secrets.env` (+ GH secrets):
+**provider auth** `TF_VAR_oci_tenancy_ocid`, `TF_VAR_oci_user_ocid`, `TF_VAR_oci_fingerprint`,
+`TF_VAR_oci_private_key` (PEM), `TF_VAR_oci_region`; **placement** `TF_VAR_oci_compartment_id`,
+`TF_VAR_oci_availability_domain`, `TF_VAR_oci_subnet_id`; and `OCI_CONTAINER_INSTANCE_OCID`
+(the Terraform output, for deploy). Auth is API-key request signing — no bearer, so no fetch-verify.
+
+## Deploy = restart (re-pull)
+
+`greenlight deploy <tool>` (oci) just runs `oci container-instances container-instance restart
+--container-instance-id <OCID>` — the instance re-pulls the latest GHCR image. The tool's CI
+builds; an event trigger (the chosen deploy option) fires the restart. The adapter does NOT build.
+
+## The idle-reclaim trap — fixed manually, NOT by code
+
+OCI **Always-Free reclaims idle compute**; pings don't count, only account standing. Convert the
+tenancy to **Pay-As-You-Go** (+ a low billing budget alarm) — a one-time manual change (see
+`docs/oci-payg-runbook.md`). Keepalive only **health-checks** + nags; it cannot stop reclaim.
+
+## Verify
+The tool is typically an **MCP server**: verify with `mode: mcp`, connect at `<name>.<domain>/mcp`
+(FastMCP's `streamable_http_app()` serves `/mcp` by default — the convention). If auth gates
+`initialize`, supply a token or use an `api`-mode 401 check. Keepalive health-checks `target: oci`.

package/assets/skills/provider-supabase/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: provider-supabase
+description: How Supabase works in a Greenlight setup — the `data: supabase` store (Postgres + auth + storage + realtime), single-project-schema-per-env model, the pause trap solved by keepalive, Management API token, and the read-only Supabase MCP. Use when wiring a tool's database, debugging a paused project, or a Supabase apply.
+---
+
+# provider-supabase
+
+`data: supabase` is for tools that need bundled **auth + storage + realtime** together
+(HeistMind). One Supabase **project**, **schema-per-env** (beta/prod share the project —
+NOT project-per-env; branching is paid). The project is **imported** (not recreated):
+name/region are replace-forcing, so the module sets `ignore_changes` to protect the live DB.
+
+## Token — `SUPABASE_ACCESS_TOKEN`
+
+Dashboard → Account → Access Tokens (Management API). Store in `.greenlight/secrets.env`;
+`greenlight add` verifies it against `/v1/projects` (HTTP 200). The DB password
+(`TF_VAR_supabase_database_password`) is only used if the project is recreated — ignored on
+import, so `import-placeholder` is fine for an existing project.
+
+## Terraform module — `infra/modules/supabase`
+
+Single project, import-safe. Outputs `url`, `anon_key`, `service_role_key`, `project_ref` —
+feed these straight into the consumer (e.g. the Vercel env block). To re-apply from fresh
+state, import first: `terraform import module.<name>_supabase.supabase_project.this <ref>`.
+
+## Keepalive — non-negotiable
+
+Supabase **pauses a free project after ~7 days idle** — this is what takes tools down. The
+**keepalive** Worker (cloudflare) pings the project on a cron. Add the tool to the aggregated
+`module.keepalive.targets_json`: `{ name, env, url = module.<name>_supabase.url, anonKey = … }`.
+The ping counts any HTTP response (even 401 on `/rest/v1/`) as alive.
+
+## MCP
+
+`.mcp.json` wires `supabase` (hosted, **read-only**): needs `SUPABASE_ACCESS_TOKEN` +
+`SUPABASE_PROJECT_REF` in the env (Claude Code expands `${VAR}` in the url/header). Run `/mcp`.
+
+## Rule
+The **blog must never use Supabase** for state (it must stay up unattended) — use D1/KV or
+external services. Supabase is per-tool, only when the bundled features are needed together.

package/assets/skills/provider-vercel/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: provider-vercel
+description: How Vercel works in a Greenlight setup — the default target for the `next` lane, configure-existing-project model (domains + env vars by project_id; deploys ride git integration), team-scoped token, and the Vercel MCP. Use when wiring a next/vercel tool, env vars, domains, or debugging a Vercel deploy.
+---
+
+# provider-vercel
+
+Vercel is the default `target` for the `next` lane. Greenlight does **not** create or deploy
+the project — it **configures an existing** Vercel project (domains + environment variables)
+by `project_id`, and the app's own repo deploys via Vercel's **git integration** (push →
+build). The wrapper owns infra; the tool repo owns deploys.
+
+## Token — `VERCEL_API_TOKEN`
+
+Account → Settings → Tokens. **Scope it to the team** that owns the project. The Terraform
+`vercel` provider also takes `team` (the `team_…` id). Store in `.greenlight/secrets.env`;
+`greenlight add` verifies it against `/v2/user` (HTTP 200) before commit.
+
+## Terraform module — `infra/modules/vercel`
+
+Manages the **existing** project (nothing to import — it configures by id):
+- `domain` → adds `<name>.<domain>` (production) + `beta.<name>.<domain>` (preview/`beta_branch`).
+- `environment` + `environment_values` → env vars per target (`production` / `preview`).
+  Wire Supabase creds straight from the `supabase` module's outputs — no manual copy (that
+  manual copy was the old fragility).
+
+The DNS CNAME is the **cloudflare** `tool` module, unproxied (`proxied = false`) → `cname.vercel-dns.com`.
+
+## MCP
+
+`.mcp.json` wires `vercel` (hosted, OAuth, read-only). Run `/mcp` and authenticate in the
+browser. Use it to read deployments, build logs, runtime logs, projects.
+
+## Gotchas
+- **ENV_CONFLICT** on apply = a var with that key/target already exists on the project. Delete
+  the pre-existing ones (Vercel dashboard or API) then re-apply, or import them.
+- The Greenlight `beta_branch` must match the repo's actual pre-prod branch (HeistMind uses
+  `development`; new tools use `develop`).
+- `next` can also target `workers` (V0/V2) — default is vercel.

package/dist/agent-web-I4LXW4SR.js

@@ -0,0 +1,7 @@
+import {
+  verifyAgentWeb
+} from "./chunk-UXHHLEYO.js";
+import "./chunk-QFKE5JKC.js";
+export {
+  verifyAgentWeb
+};