Add repo scaffolding to meet repository standards

Add .gitignore, LICENSE (MIT), Makefile, Dockerfile, .dockerignore,
and pin prettier via yarn lockfile for integrity-checked markdown
formatting. Update REPO_POLICIES.md self-reference to point to this
repo. Format markdown files with prettier.

.dockerignore

@@ -0,0 +1,3 @@
+.git
+node_modules
+.DS_Store

.gitignore

@@ -0,0 +1,5 @@
+.DS_Store
+*.swp
+*.swo
+*~
+node_modules/

Dockerfile

@@ -0,0 +1,11 @@
+# node 22-alpine, 2026-02-22
+FROM node@sha256:e4bf2a82ad0a4037d28035ae71529873c069b13eb0455466ae0bc13363826e34
+
+RUN apk add --no-cache make
+
+WORKDIR /app
+COPY package.json yarn.lock ./
+RUN yarn install --frozen-lockfile
+COPY . .
+
+RUN make check

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 sneak
+
+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.

Makefile

@@ -0,0 +1,21 @@
+.PHONY: test lint fmt fmt-check check docker
+
+PRETTIER := yarn run prettier
+
+test:
+	@echo "No tests defined."
+
+lint:
+	@echo "Linting markdown files..."
+	@$(PRETTIER) --check '**/*.md' --tab-width 4
+
+fmt:
+	@$(PRETTIER) --write '**/*.md' --tab-width 4
+
+fmt-check:
+	@$(PRETTIER) --check '**/*.md' --tab-width 4
+
+check: test lint fmt-check
+
+docker:
+	docker build -t prompts .

REPO_POLICIES.md

@@ -0,0 +1,110 @@
+# Development Policies
+
+- Docker image references by tag are server-mutable, therefore using them is
+  an RCE vulnerability. All docker image references must use cryptographic
+  hashes to securely specify the exact image that is expected.
+
+- Correspondingly, `go install` commands using things like '@latest' are
+  also dangerous RCE. Whenever writing scripts or tools, ALWAYS specify go
+  install targets using commit hashes which are cryptographically secure.
+
+- Every repo with software in it must have a Makefile in the root. Each
+  such Makefile should support `make test` (runs the project-specific
+  tests), `make lint`, `make fmt` (writes), `make fmt-check` (readonly), and
+  `make check` (has `test`, `lint`, and `fmt-check` as prereqs), `make
+docker` (builds docker image).
+
+- Every repo should have a Dockerfile. If the repo contains non-server
+  software, the Dockerfile should bring up a development environment and
+  `make check` (i.e. the docker build should fail if the branch is not
+  green).
+
+- Platform-specific standard formatting should be used. `black` for python,
+  `prettier` for js/css/etc, `go fmt` for go. The only changes to default
+  settings should be to specify four-space indents where applicable (i.e.
+  everything except `go fmt`).
+
+- If local testing is possible (it is not always), `make check` should be a
+  pre-commit hook. If it is not possible, `make lint && make fmt-check`
+  should be a pre-commit hook.
+
+- If a working `make test` takes more than 20 seconds, that's a bug that
+  needs fixing. In fact, there should be a timeout specified in the
+  `Makefile` that fails it automatically if it takes >30s.
+
+- Docker builds should time out in 5 minutes or less.
+
+- `main` must always pass `make check`, no exceptions.
+
+- Do all changes on a feature branch. You can do whatever you want on a
+  feature branch.
+
+- We have a standardized `.golangci.yml` which we reuse and is _NEVER_ to be
+  modified by an agent, only manually by the user. It can be copied from
+  `~/dev/upaas/.golangci.yml` if it exists at that location.
+
+- When specifying images or packages by hash in Dockerfiles or
+  `docker-compose.yml`, put a comment above the line and show the version
+  and date at which it was current.
+
+- For javascript, always use `yarn` over `npm`.
+
+- Whenever writing dates, ALWAYS write YYYY-MM-DD (ISO 8601).
+
+- Simple projects should be configured with environment variables, as is
+  standard for Dockerized applications.
+
+- Dockerized web services should listen on the default HTTP port of 8080
+  unless overridden with the `PORT` environment variable.
+
+- The `README.md` is a project's primary documentation. It should contain
+  at a minimum the following sections:
+    - Description
+        - Include a short and complete description of the functionality and
+          purpose of the software as the first line in the readme. It must
+          include:
+            - the name
+            - the purpose
+            - the category (web server, SPA, command line tool, etc)
+            - the license
+            - the author
+            - eg: "µPaaS is an MIT-licensed Go web application by @sneak
+              that receives git-frontend webhooks and interacts with a
+              Docker server to build and deploy applications in realtime as
+              certain branches are updated."
+    - Getting Started
+        - a code block with copy-pasteable installation/use sections
+    - Rationale
+        - why does this exist?
+    - Design
+        - how is the program structured?
+    - TODO
+        - This is your TODO list for the project - update it meticulously,
+          even in between commits. Whenever planning, put your todo list in
+          the README so that a separate agent with new context can pick up
+          where you left off.
+    - License
+        - GPL or MIT or WTFPL - ask the user when beginning a new project
+          and include a LICENSE file in the root and in a section in the
+          README.
+    - Author
+        - @sneak (link `@sneak` to `https://sneak.berlin`).
+
+- When beginning a new project, initialize a git repo and make the first
+  commit simply the first version of the README.md in the root of the repo.
+
+- For Go packages, the module root is `sneak.berlin/go/...`, such
+  as `sneak.berlin/go/dnswatcher`.
+
+- We use SemVer always.
+
+- If no tag `1.0.0` or greater exists in the repository, modify the existing
+  migrations and assume no installed base or existing databases. If
+  `>=1.0.0`, database changes add new migration files.
+
+- New repos must have at a minimum the following files:
+    - `README.md`, `.git`, `.gitignore`
+    - `REPO_POLICIES.md` (copy from the `prompts` repo)
+    - `Dockerfile`, `.dockerignore`
+    - for go: `go.mod`, `go.sum`, `.golangci.yml`
+    - for js: `package.json`

package.json

@@ -0,0 +1,5 @@
+{
+  "devDependencies": {
+    "prettier": "3.8.1"
+  }
+}

yarn.lock

@@ -0,0 +1,8 @@
+# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
+# yarn lockfile v1
+
+
+prettier@3.8.1:
+  version "3.8.1"
+  resolved "https://registry.yarnpkg.com/prettier/-/prettier-3.8.1.tgz#edf48977cf991558f4fcbd8a3ba6015ba2a3a173"
+  integrity sha512-UOnG6LftzbdaHZcKoPFtOcCKztrQ57WkHDeRD9t/PTQtmT0NHSeWWepj6pS0z/N7+08BHFDQVUrfmfMRcZwbMg==