The ops/ directory is intended as a semi-organized dumping ground for various types of programs and scripts that exist around the application, but are not actually part of it. (E.g., they will not get deployed, but they might be used to deploy the app.)

It's intended to be neither totally chaotic, nor totally pristine.

Stuff in this directory is expected to begin life as crappy Shell scripts, and, depending on needs, possibly evolve into e.g. Python or Go programs.

It can be used for

development tools and helpers
build and CI scripts
unwieldy integration tests
environment setup / teardown
recurring complex operations that are part of the dev flow (e.g., testing out the schema of an external API)
data visualizations

Purpose

This is an experimental pattern that I'm trying out. It's basically like "scripts/", but it follows the "3-letter top level directory" convention.

It's also less constraining than "scripts", which would appear to disallow things like full Go programs, which I explicitly want to allow, and would actually consider desirable.

Shell scripts are fragile and finicky by nature. For example, any kind of error handling is notoriously difficult in Shell. Yet, error states are extremely common in anything that you're using Shell for:

network failures
some file doesn't exist / already exists
permission denied
some string variable is empty

Therefore, it's natural that important tasks should eventually be implemented using a proper programming language. Beyond a certain level of effort, "Just write it in Go" is actually easier. Or at least Python.