Merge pull request 'REPO_POLICIES: expand pre-1.0 schema migration rule (closes #5)' (#6) from clawbot/prompts:pre-1.0-migration-rule into main

Reviewed-on: #6

README.md

@@ -115,6 +115,31 @@ subdirectory. Each file contains one or more related prompts or policy
 documents. There is no build step or runtime component; the prompts are consumed
 by copying them into other projects or referencing them directly.
 
+## Template Repos
+
+These template repositories implement the policies defined in this repo and
+serve as starting points for new projects. They must be kept in sync when
+policies change.
+
+- **[template-app-go](https://git.eeqj.de/sneak/template-app-go)** — Go HTTP
+  server template (Uber fx, chi, SQLite, session auth, Prometheus metrics)
+- **[template-app-js](https://git.eeqj.de/sneak/template-app-js)** — JavaScript
+  SPA template (Vite, Tailwind CSS v4, nginx Docker deployment)
+- **[template-app-python](https://git.eeqj.de/sneak/template-app-python)** —
+  Python web application template (FastAPI, uvicorn, pytest, black, ruff)
+
+When updating policies in this repo, also update the template repos to match
+(Makefile targets, Dockerfile conventions, CI workflows, required files, etc.).
+
+## See Also
+
+- **[clawpub](https://git.eeqj.de/sneak/clawpub)** — Real-world examples,
+  rationale, and operational lessons from applying these policies with an
+  [OpenClaw](https://github.com/openclaw/openclaw) AI agent. Includes detailed
+  documentation on how the interlocking check system (CI → Docker → Makefile →
+  tests/lint/fmt) works in practice, why checklists complement prose policies,
+  and failure stories from production use.
+
 ## TODO
 
 - Add more prompt templates for common development tasks

prompts/CODE_STYLEGUIDE_GO.md

@@ -229,6 +229,29 @@ last_modified: 2026-02-22
 
 1.  Define your struct types near their constructors.
 
+1.  Do not create packages whose sole purpose is to hold type definitions.
+    Packages named `types`, `domain`, or `models` that contain only structs and
+    interfaces (with no behavior) are a code smell. Define types alongside the
+    code that uses them. Type-only packages force consuming packages into alias
+    imports and circular-dependency gymnastics, and indicate that the package
+    boundaries were drawn around nouns instead of responsibilities. If multiple
+    packages need the same type, put it in the package that owns the behavior,
+    or in a small, focused interface package — not in a grab-bag types package.
+
+1.  When defining custom string-based types (e.g. `type ImageID string`),
+    implement `fmt.Stringer`. Use `.String()` at SDK and library boundaries
+    instead of `string(v)`. This makes type conversions explicit, grep-able, and
+    consistent across the codebase. Example:
+
+    ```go
+    type ContainerID string
+
+    func (id ContainerID) String() string { return string(id) }
+
+    // At the Docker SDK boundary:
+    resp, err := c.docker.ContainerStart(ctx, id.String(), opts)
+    ```
+
 1.  Define your interface types near the functions that use them, or if you have
     multiple conformant types, put the interface(s) in their own file.
 

prompts/REPO_POLICIES.md

@@ -144,8 +144,14 @@ style conventions are in separate documents:
 - Use SemVer.
 
 - Database migrations live in `internal/db/migrations/` and must be embedded in
-  the binary. Pre-1.0.0: modify existing migrations (no installed base assumed).
-  Post-1.0.0: add new migration files.
+  the binary.
+  - `000_migration.sql` — contains ONLY the creation of the migrations tracking
+    table itself. Nothing else.
+  - `001_schema.sql` — the full application schema.
+  - **Pre-1.0.0:** never add additional migration files (002, 003, etc.). There
+    is no installed base to migrate. Edit `001_schema.sql` directly.
+  - **Post-1.0.0:** add new numbered migration files for each schema change.
+    Never edit existing migrations after release.
 
 - All repos should have an `.editorconfig` enforcing the project's indentation
   settings.