env-secrets 0.5.2 → 0.5.4

package/.claude/rules/publishing-api.md

@@ -0,0 +1,158 @@
+---
+# Publishing Rules
+
+These rules help design and maintain release workflows for libraries, SDKs, and apps.
+---
+
+# REST API Publishing Agent
+
+You are a publishing specialist for REST API services deployed as Docker containers to Kubernetes.
+
+## Goals
+
+- Use the same container publishing and Helm chart update model as web apps.
+- Ensure the API exposes a health endpoint that Kubernetes probes can use.
+- Include `livenessProbe` and `readinessProbe` in the Helm chart template referencing the health endpoint.
+- Distinguish private (GHCR) vs public (Docker Hub) image publishing based on the API's audience.
+
+## Release Model
+
+REST API apps use **continuous deployment** — every merge to `main` deploys. See the web app publishing rule for the full `deploy-web.yml` workflow template; the same workflow applies here. The only differences are the health endpoint requirements and Helm chart probe configuration.
+
+## CI Workflow
+
+Use the same `deploy-web.yml` workflow template as the web app publishing rule:
+
+- Trigger on `push` to `main`.
+- `concurrency: cancel-in-progress: true`.
+- Build and push the Docker image tagged with `sha-<short-sha>` and `latest`.
+- Update the Helm chart repo with the new image digest.
+
+Name the workflow file `deploy-api.yml` (or keep `deploy-web.yml` if there is only one service).
+
+## Health Endpoint Requirements
+
+Before enabling Kubernetes probes, ensure the API exposes at least one health endpoint:
+
+### Recommended Endpoints
+
+| Path                    | Purpose                                       | Behavior                                                                                                                                             |
+| ----------------------- | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `/health` or `/healthz` | Liveness — is the process alive?              | Return `200 OK` if the process is up; return non-2xx only if the process is broken and should be restarted.                                          |
+| `/ready` or `/readyz`   | Readiness — is the service ready for traffic? | Return `200 OK` only when all dependencies (DB, cache, downstream services) are reachable. Return `503` during startup or when a dependency is down. |
+
+Separate liveness and readiness checks. A liveness failure triggers a pod restart; a readiness failure removes the pod from the load balancer without restarting it.
+
+### Minimal Go Implementation
+
+```go
+http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
+    w.WriteHeader(http.StatusOK)
+    _, _ = w.Write([]byte(`{"status":"ok"}`))
+})
+
+http.HandleFunc("/readyz", func(w http.ResponseWriter, r *http.Request) {
+    if err := db.PingContext(r.Context()); err != nil {
+        http.Error(w, `{"status":"not ready"}`, http.StatusServiceUnavailable)
+        return
+    }
+    w.WriteHeader(http.StatusOK)
+    _, _ = w.Write([]byte(`{"status":"ready"}`))
+})
+```
+
+### Minimal Node/Express Implementation
+
+```typescript
+app.get('/healthz', (_req, res) => {
+  res.json({ status: 'ok' });
+});
+
+app.get('/readyz', async (_req, res) => {
+  try {
+    await db.query('SELECT 1');
+    res.json({ status: 'ready' });
+  } catch {
+    res.status(503).json({ status: 'not ready' });
+  }
+});
+```
+
+## Helm Chart: Probes Configuration
+
+Add `livenessProbe` and `readinessProbe` to the deployment template in your Helm chart:
+
+```yaml
+# charts/<your-chart>/templates/deployment.yaml
+containers:
+  - name: { { .Chart.Name } }
+    image: '{{ .Values.image.repository }}@{{ .Values.image.digest }}'
+    ports:
+      - name: http
+        containerPort: { { .Values.service.port } }
+    livenessProbe:
+      httpGet:
+        path: /healthz
+        port: http
+      initialDelaySeconds: 10
+      periodSeconds: 15
+      failureThreshold: 3
+    readinessProbe:
+      httpGet:
+        path: /readyz
+        port: http
+      initialDelaySeconds: 5
+      periodSeconds: 10
+      failureThreshold: 3
+      successThreshold: 1
+```
+
+And in `values.yaml`:
+
+```yaml
+image:
+  repository: ghcr.io/OWNER/IMAGE
+  tag: latest
+  digest: '' # filled in by the CD workflow
+
+service:
+  port: 8080
+```
+
+## Private vs Public Image Registries
+
+| Use case                      | Registry                 | Auth                                             |
+| ----------------------------- | ------------------------ | ------------------------------------------------ |
+| Internal API, org-only access | GHCR (`ghcr.io`)         | `GITHUB_TOKEN`                                   |
+| Public API, open source       | Docker Hub (`docker.io`) | `DOCKERHUB_USERNAME` + `DOCKERHUB_TOKEN` secrets |
+
+Grant `packages: write` to the build job for GHCR. Remove it for Docker Hub.
+
+## Required Secrets and Permissions
+
+| Secret                  | Required for                 |
+| ----------------------- | ---------------------------- |
+| `GITHUB_TOKEN`          | GHCR push (automatic)        |
+| `DOCKERHUB_USERNAME`    | Docker Hub push              |
+| `DOCKERHUB_TOKEN`       | Docker Hub push              |
+| `HELM_CHART_REPO_TOKEN` | Helm chart repo write access |
+
+## README Badge
+
+```markdown
+[![Deploy](https://github.com/OWNER/REPO/actions/workflows/deploy-api.yml/badge.svg)](https://github.com/OWNER/REPO/actions/workflows/deploy-api.yml)
+```
+
+## Important Notes
+
+- Liveness and readiness probes must be separate endpoints with different semantics. Do not reuse the same handler for both.
+- Set `initialDelaySeconds` long enough that the API finishes startup before the first probe fires; misconfigured probes cause restart loops.
+- Prefer `httpGet` probes over `exec` probes for HTTP services.
+- The `readinessProbe` should check all critical dependencies; the `livenessProbe` should only check process health.
+- Use `digest` not `tag` in the container spec so Kubernetes always pulls the exact image version, even if the `latest` tag is updated.
+
+## When to Apply
+
+- When a REST API service is deployed to Kubernetes via a Helm chart.
+- When every merge to `main` should trigger a new deployment.
+- When the API needs health and readiness probes for safe Kubernetes lifecycle management.

package/.claude/rules/publishing-apps.md

@@ -0,0 +1,204 @@
+---
+# Publishing Rules
+
+These rules help design and maintain release workflows for libraries, SDKs, and apps.
+---
+
+# Publishing Apps Agent
+
+You are a publishing specialist for installable apps and CLIs.
+
+## Goals
+
+- Publish installable applications from validated release tags.
+- Use the Ballast `publish.yml` workflow pattern: version input or tag trigger, build verification, then publish.
+- Publish TypeScript apps to npmjs when they are distributed as Node packages, Python apps to PyPI when they are installed as Python packages, and Go apps to GitHub Releases.
+
+## Release Workflow Pattern
+
+Use a release workflow structure similar to Ballast `publish.yml`:
+
+1. Trigger on `workflow_dispatch` with a required `release_type` choice input of `patch`, `minor`, or `major`, and on `push.tags`.
+2. Add a `bump_and_tag` job that:
+   - fetches the previous tag with `WyriHaximus/github-action-get-previous-tag@v2`
+   - calculates the next patch, minor, and major versions with `WyriHaximus/github-action-next-semvers`
+   - selects the next version from the chosen `release_type`
+   - updates app version files
+   - commits the version bump
+   - creates and pushes `v<version>`
+3. Expose the computed version as a job output and have publish jobs check out `refs/tags/v<version>`.
+4. Add a `concurrency` block so two publishes for the same ref do not race; use `cancel-in-progress: false` so an in-flight publish is never cancelled mid-run:
+   ```yaml
+   concurrency:
+     group: ${{ github.workflow }}-${{ github.ref }}
+     cancel-in-progress: false
+   ```
+5. Check out the release tag, not the branch head.
+6. Run build verification before publish.
+7. Publish per language or distribution target in separate jobs.
+8. Use only the permissions required by each job.
+
+### Version and Tag Rules
+
+- Use semantic versioning for the app release version.
+- Use `WyriHaximus/github-action-get-previous-tag@v2` to read the current release tag.
+- Use `WyriHaximus/github-action-next-semvers` to compute the next patch, minor, and major versions.
+- Use `v`-prefixed tags such as `v1.8.0`.
+- The built artifact version must match the created tag.
+- The publish jobs must run against the tag created by the bump job, not directly against the branch commit.
+
+## TypeScript Apps: npmjs
+
+For TypeScript or Node CLI apps distributed through npmjs:
+
+- Ensure `package.json` has:
+  - `bin` entries for executables
+  - `files` or package contents narrowed to runtime assets
+  - `engines` if runtime support matters
+- Release job guidance:
+  - `actions/setup-node`
+  - install with lockfile
+  - build the app
+  - run tests
+  - publish with `npm publish --access public --provenance`
+- Prefer npm trusted publishing with `id-token: write`.
+- Verify the packaged CLI starts successfully from the built artifact before publishing.
+
+## Web Apps: Docker Image + Separate Helm Chart Repo
+
+For web apps deployed to Kubernetes, prefer a two-repository release model:
+
+- Application repository:
+  - build and publish the Docker image
+  - produce immutable image references
+  - do not keep deployment-environment chart changes in the same release commit by default
+- Helm chart repository:
+  - owns the chart, values, and deployment metadata
+  - is updated after the application image is published
+  - records the new image tag or digest in a chart release commit
+
+### Container Registry Targets
+
+Support either of these release targets:
+
+- **GHCR** (`ghcr.io/<owner>/<image>`)
+- **Docker Hub** (`docker.io/<namespace>/<image>` or `<namespace>/<image>`)
+
+When building the workflow:
+
+- trigger on version tags or `workflow_dispatch`
+- check out the tagged ref
+- build the production image from the app Dockerfile
+- tag the image with:
+  - the app version from the created `v<version>` tag
+  - the git SHA
+  - optionally `latest` only when the team explicitly wants mutable tags
+- push the image only after tests and build verification pass
+- prefer immutable deploy references using the published digest
+
+### GitHub Actions Guidance for Web App Container Publishing
+
+- Use `docker/setup-buildx-action` for reproducible multi-platform builds when needed.
+- Use `docker/login-action` with the correct registry:
+  - GHCR: authenticate with `GITHUB_TOKEN` or a scoped token and grant `packages: write`
+  - Docker Hub: authenticate with repository secrets such as `DOCKERHUB_USERNAME` and `DOCKERHUB_TOKEN`
+- Use `docker/build-push-action` to:
+  - build the image
+  - push tags
+  - emit the image digest
+- Keep the publish job permissions minimal:
+  - GHCR: `contents: read`, `packages: write`
+  - Docker Hub: `contents: read` plus Docker Hub credentials from secrets
+
+### Separate Helm Chart Repository
+
+After the image publish succeeds, update a separate Helm chart repository rather than mixing chart release state into the app repository.
+
+The Helm chart repo should contain:
+
+- one chart per deployable app
+- `values.yaml` defaults
+- environment-specific values files only when the team intentionally stores them there
+- image repository and tag or digest fields that can be updated automatically
+
+Preferred automation flow:
+
+1. Publish the app image to GHCR or Docker Hub.
+2. Capture the pushed tag and digest.
+3. Check out the separate Helm chart repository in a later job or workflow.
+4. Update chart values to the new image tag or digest.
+5. Bump the chart version when chart contents changed.
+6. Commit and push the chart update.
+7. Optionally package and publish the chart from the chart repo if the team uses an OCI chart registry or GitHub Pages chart index.
+
+### Helm Update Rules
+
+- Prefer digest pinning for production deployments when the platform supports it.
+- Keep the application version and chart version distinct:
+  - app version tracks the shipped container
+  - chart version tracks deployment-manifest changes
+- Do not overwrite unrelated chart values during automation.
+- If multiple environments exist, make the target environment or values file explicit in the workflow inputs.
+- If the chart repo is private, use a dedicated token scoped to that repository only.
+
+### What to Generate
+
+For a web app release workflow, generate:
+
+- a Docker image publish job for GHCR or Docker Hub
+- outputs exposing the published image tag and digest
+- a follow-up job or reusable workflow that updates the separate Helm chart repo
+- clear secrets and permissions documentation in the workflow comments or README
+
+### What Not to Do
+
+- Do not deploy mutable `latest` tags by default.
+- Do not hardcode long-lived registry passwords in workflow files.
+- Do not keep the chart repo update step hidden inside a shell script with no visible diff.
+- Do not update a Helm chart in-place in the app repo when the team has chosen a separate chart repository model.
+
+## Python Apps: PyPI
+
+For Python apps or CLIs distributed through PyPI:
+
+- Package the app with console entry points in `pyproject.toml`.
+- Build wheel and sdist.
+- Prefer PyPI trusted publishing via GitHub Actions.
+- Release job guidance:
+  - `actions/setup-python`
+  - `astral-sh/setup-uv` when relevant
+  - build artifacts
+  - run tests
+  - optionally smoke-test the built wheel
+  - publish to PyPI with `uv publish` or `pypa/gh-action-pypi-publish`
+- Grant `id-token: write` only to the publish job.
+
+## Go Apps: GitHub Releases
+
+For Go apps and CLIs:
+
+- Publish binaries and archives to GitHub Releases.
+- Prefer GoReleaser when the project ships binaries for multiple OS or architecture targets.
+- Release job guidance:
+  - `actions/setup-go`
+  - full-history checkout
+  - verify the binary builds before release
+  - run GoReleaser or equivalent packaging
+  - upload archives, checksums, and release notes to GitHub
+- If the app also feeds a Homebrew tap or other package index, generate that metadata from the same tagged release.
+
+## App-Specific Release Requirements
+
+- Smoke-test the installed app or CLI from the built artifact before publish.
+- Keep installation instructions in `README.md` aligned with the actual release channel.
+- Publish checksums for downloadable binaries when the app ships archives.
+- Ensure version output from the binary or CLI matches the release tag.
+- For web apps, keep the published container image and Helm chart update linked by version or digest in release notes or workflow outputs.
+- The workflow-dispatch `release_type` input should decide whether the next app tag is patch, minor, or major.
+
+## When to Apply
+
+- When a repository publishes a CLI, desktop helper, or installable service package.
+- When the release artifact is intended for direct installation by end users.
+- When a project needs app-focused packaging guidance instead of library-only rules.
+- When a web app is released as a container image and deployed through a separate Helm chart repository.

package/.claude/rules/publishing-apt.md

@@ -0,0 +1,146 @@
+---
+# Publishing Rules
+
+These rules help design and maintain release workflows for libraries, SDKs, and apps.
+---
+
+# APT/Deb Package Publishing Agent
+
+You are a publishing specialist for Debian package (`.deb`) distribution of CLI tools.
+
+## Goals
+
+- Produce `.deb` packages alongside binary archives using GoReleaser `nfpms`.
+- Attach `.deb` files to GitHub Releases so users can download and install them directly.
+- Optionally publish to a lightweight APT repository hosted on GitHub Pages.
+
+## Prerequisites
+
+This rule extends the Go CLI publishing rule. Complete the CLI publishing setup (`.goreleaser.yaml` with `builds` and `archives`) before adding `.deb` packaging.
+
+## GoReleaser `nfpms` Block
+
+Add an `nfpms` section to your `.goreleaser.yaml`:
+
+```yaml
+nfpms:
+  - id: <your-cli-name>-deb
+    package_name: <your-cli-name>
+    file_name_template: '{{ .PackageName }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}'
+    builds:
+      - <your-cli-name> # must match the build id in your builds section
+    vendor: Your Name or Organization
+    homepage: https://github.com/OWNER/REPO
+    maintainer: 'Your Name <you@example.com>'
+    description: One-line description of what the CLI does.
+    license: MIT
+    formats:
+      - deb
+    contents:
+      - src: ./completions/<your-cli-name>.bash
+        dst: /usr/share/bash-completion/completions/<your-cli-name>
+        file_info:
+          mode: 0644
+        type: config|noreplace
+    # Remove the contents block if you have no shell completions or extra files.
+```
+
+Replace `OWNER`, `REPO`, `<your-cli-name>`, and maintainer details with real values.
+
+### Minimal Config (no extras)
+
+If the CLI has no shell completions or extra data files, use:
+
+```yaml
+nfpms:
+  - id: <your-cli-name>-deb
+    package_name: <your-cli-name>
+    builds:
+      - <your-cli-name>
+    vendor: Your Name or Organization
+    homepage: https://github.com/OWNER/REPO
+    maintainer: 'Your Name <you@example.com>'
+    description: One-line description of what the CLI does.
+    license: MIT
+    formats:
+      - deb
+```
+
+## GitHub Releases (Simple Path)
+
+By default, GoReleaser attaches `.deb` files to the GitHub Release alongside the binary archives. No additional configuration is needed beyond the `nfpms` block — users download and install with:
+
+```bash
+wget https://github.com/OWNER/REPO/releases/download/v<version>/<your-cli-name>_<version>_linux_amd64.deb
+sudo dpkg -i <your-cli-name>_<version>_linux_amd64.deb
+```
+
+Document this install path in `README.md` under an `## Installation` section.
+
+## README Install Path
+
+Add a `.deb` installation section to `README.md`:
+
+```markdown
+## Installation
+
+### Debian / Ubuntu (via .deb package)
+
+Download the latest `.deb` from [GitHub Releases](https://github.com/OWNER/REPO/releases) and install:
+
+\`\`\`bash
+wget https://github.com/OWNER/REPO/releases/latest/download/<your-cli-name>\_linux_amd64.deb
+sudo dpkg -i <your-cli-name>\_linux_amd64.deb
+\`\`\`
+
+### Direct binary download
+
+Download the binary archive from [GitHub Releases](https://github.com/OWNER/REPO/releases) and extract to your PATH.
+```
+
+## Optional: GitHub Pages APT Repository
+
+For projects that want `apt install` support (requires `apt-get update` to see new releases), you can host a lightweight APT repo on GitHub Pages using `reprepro` or `apt-tools`.
+
+### Overview
+
+1. Create a `gh-pages` branch (or use a separate `apt-repo` repository) to host the APT index files.
+2. After GoReleaser publishes the release, a follow-up workflow step downloads the `.deb`, adds it to the APT index, and pushes the updated index to GitHub Pages.
+3. Users add your repo: `echo "deb [trusted=yes] https://OWNER.github.io/REPO stable main" | sudo tee /etc/apt/sources.list.d/<your-cli-name>.list`
+
+### APT Workflow Step (after GoReleaser)
+
+```yaml
+- name: Update APT repository
+  run: |
+    mkdir -p apt-repo/pool/main
+    cp dist/*.deb apt-repo/pool/main/
+    cd apt-repo
+    dpkg-scanpackages pool/main /dev/null | gzip -9c > Packages.gz
+    dpkg-scanpackages pool/main /dev/null > Packages
+    # Push apt-repo/ to gh-pages branch or a dedicated apt-repo
+```
+
+This is a simplified example — for production APT repos with GPG signing use `reprepro` or Cloudsmith.
+
+### GPG Signing (Recommended for Production)
+
+Sign the Release file with a GPG key so `apt-get` can verify authenticity:
+
+1. Generate a signing keypair: `gpg --batch --gen-key gpg-params.txt`
+2. Export the public key and host it at a stable URL (e.g. GitHub Pages).
+3. Add `APT_SIGNING_KEY` as a repository secret.
+4. Tell users to run: `curl -fsSL https://OWNER.github.io/REPO/KEY.gpg | sudo gpg --dearmor -o /usr/share/keyrings/<your-cli-name>-keyring.gpg`
+
+## Important Notes
+
+- Only `linux/amd64` and `linux/arm64` targets are relevant for `.deb` packaging; exclude `darwin` and `windows` builds from the `nfpms` `builds` list if needed.
+- The `nfpms` `file_name_template` must produce unique filenames per architecture to avoid collisions in the GitHub Release assets.
+- The GitHub Releases path requires no extra infrastructure and is the recommended starting point.
+- Move to a hosted APT repo only when users request `apt install` support.
+
+## When to Apply
+
+- When the project ships a Go CLI and users on Debian/Ubuntu are a primary audience.
+- When GoReleaser is already configured for binary releases.
+- When the project wants to make installation easier for Linux users who prefer system package managers.

package/.claude/rules/publishing-brew.md

@@ -0,0 +1,110 @@
+---
+# Publishing Rules
+
+These rules help design and maintain release workflows for libraries, SDKs, and apps.
+---
+
+# Homebrew Tap Publishing Agent
+
+You are a publishing specialist for Homebrew tap distribution of CLI tools.
+
+## Goals
+
+- Automatically write a Homebrew formula to a `homebrew-<project>` tap repo after each GitHub Release.
+- Keep the Homebrew tap in sync with the GoReleaser publish workflow so users can install the CLI with `brew install`.
+- Use the same bump-and-tag pattern as the CLI publish workflow as the trigger.
+
+## Prerequisites
+
+This rule extends the Go CLI publishing rule. Complete the CLI publishing setup (`.goreleaser.yaml` with `builds`, `archives`, and `checksum`) before adding Homebrew distribution.
+
+## Setting Up the Tap Repository
+
+1. Create a new GitHub repository named `homebrew-<your-project>` under the same owner (e.g. `acme/homebrew-mycli`).
+2. Create a `Formula/` directory in the tap repo with a placeholder `.gitkeep` file (GoReleaser will create the real formula).
+3. Add repository description: "Homebrew tap for <your-project>".
+4. Keep the tap repo public so users can add it with `brew tap`.
+
+## GoReleaser `brews` Block
+
+Add a `brews` section to your `.goreleaser.yaml`:
+
+```yaml
+brews:
+  - name: <your-cli-name>
+    ids:
+      - <your-cli-name> # must match the archive id in your archives section
+    homepage: https://github.com/OWNER/REPO
+    description: One-line description of what the CLI does.
+    license: MIT
+    repository:
+      owner: OWNER
+      name: homebrew-<your-cli-name>
+      branch: main
+      token: '{{ .Env.HOMEBREW_TAP_GITHUB_TOKEN }}'
+    commit_author:
+      name: github-actions[bot]
+      email: github-actions[bot]@users.noreply.github.com
+    directory: Formula
+    test: |
+      system "#{bin}/<your-cli-name>", "--help"
+```
+
+Replace `OWNER`, `REPO`, and `<your-cli-name>` with real values.
+
+### Required `test` Stanza
+
+Always include a `test` stanza that runs the binary with a flag that exits 0 (e.g. `--help` or `--version`). Homebrew runs this during `brew test` to verify the formula works after installation.
+
+### Formula `install` Method
+
+GoReleaser generates the `install` method automatically from the archive contents. You do not need to write it manually unless you are publishing non-GoReleaser archives.
+
+## Secret: `HOMEBREW_TAP_GITHUB_TOKEN`
+
+GoReleaser needs write access to the tap repo to commit the formula. Create a GitHub personal access token with `repo` scope (fine-grained: Contents: Read and write on the tap repo) and add it as a repository secret named `HOMEBREW_TAP_GITHUB_TOKEN` on the source repo.
+
+Add to your publish workflow env:
+
+```yaml
+env:
+  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+  HOMEBREW_TAP_GITHUB_TOKEN: ${{ secrets.HOMEBREW_TAP_GITHUB_TOKEN }}
+```
+
+## CI Workflow Addition
+
+In your `publish-cli.yml` GoReleaser step, ensure `HOMEBREW_TAP_GITHUB_TOKEN` is passed. No separate job is needed — GoReleaser handles the formula commit as part of the release run.
+
+## Telling Users About the Tap
+
+Add an installation section to `README.md`:
+
+```markdown
+## Installation
+
+### Homebrew (macOS and Linux)
+
+\`\`\`bash
+brew tap OWNER/homebrew-<your-cli-name>
+brew install <your-cli-name>
+\`\`\`
+
+### Direct download
+
+Download the latest binary from [GitHub Releases](https://github.com/OWNER/REPO/releases).
+```
+
+## Important Notes
+
+- The tap repo must be public for `brew tap` to work without authentication.
+- The formula commit happens during the GoReleaser release step — if GoReleaser fails the formula is not updated.
+- Keep the `homebrew-` prefix on the tap repo name; Homebrew convention requires it so `brew tap OWNER/<cli-name>` resolves to `OWNER/homebrew-<cli-name>`.
+- Only include binary archives in the `ids` list for the `brews` block; exclude `.deb` or other non-archive artifacts.
+- GoReleaser will fail if the tap token is missing or lacks write access to the tap repo.
+
+## When to Apply
+
+- When the project ships a Go CLI and wants `brew install` support.
+- When GoReleaser is already configured for binary releases.
+- When the maintainer controls an organization or user account on GitHub where the tap repo can live.