Version: 1.0.0 Protocol Version: 2024-11-05 Last Updated: 2026-01-10
🆕 Update: See more extensive repo here: https://github.com/marckohlbrugge/unofficial-37signals-coding-style-guide
This style guide was generated by Claude Code through deep analysis of the Fizzy codebase - 37signals' open-source project management tool.
Why Fizzy matters: While 37signals has long advocated for "vanilla Rails" and opinionated software design, their production codebases (Basecamp, HEY, etc.) have historically been closed source. Fizzy changes that. For the first time, developers can study a real 37signals/DHH-style Rails application - not just blog posts and conference talks, but actual production code with all its patterns, trade-offs, and deliberate omissions.
Reimplement the current branch on a new branch with a clean, narrative-quality git commit history suitable for reviewer comprehension.
-
Validate the source branch
- Ensure the current branch has no merge conflicts, uncommitted changes, or other issues.
- Confirm it is up to date with
main.
-
Analyze the diff
- Study all changes between the current branch and
main.
Z‑Image Turbo is a bit different from “classic” Stable Diffusion, so a lot of old prompting habits don’t quite apply. I’ll walk through how to prompt it deeply and safely, with special focus on controlling content (nudity, stereotypes, unwanted artifacts) even though the model does not support traditional negative prompts at all. ([Hugging Face][1])
Key facts that matter for prompting:
lnr is an append-only, file-based lnr work management system designed for AI coding agents. Lnr work is organized into phases - coherent units of effort that match how AI agents naturally operate. The system requires no indices, no status tracking, and no complex tooling. State is derived entirely from which files exist in the directory.
Lnr work happens in phases, not issues or tickets. Each phase represents a coherent push toward a specific goal. Phases can be small (refactor a function) or large (implement authentication system).
| CONFIG WAS UPDATED - SEE COMMENTS | |
| DEPRECATED | |
| # This file contains pin mappings for the NON stock 2020 Creality Ender 3 | |
| # with the 32-bit Creality 4.2.2 board. To use this config, during | |
| # "make menuconfig" select the STM32F103 with a "28KiB bootloader" and | |
| # serial (on USART1 PA10/PA9) communication. | |
| # adapted for my printer ender3-4.2.2 with some modifications and without the BLTouch. | |
| # If you prefer a direct serial connection, in "make menuconfig" |
| import plotly.graph_objects as go | |
| import pandas as pd | |
| def serp_heatmap(df, num_domains=10, select_domain=None): | |
| df = df.rename(columns={'domain': 'displayLink', | |
| 'searchTerms': 'keyword'}) | |
| top_domains = df['displayLink'].value_counts()[:num_domains].index.tolist() | |
| top_domains = df['displayLink'].value_counts()[:num_domains].index.tolist() | |
| top_df = df[df['displayLink'].isin(top_domains) & df['displayLink'].ne('')] |
| # Rails production setup via SQLite3 made durable by https://litestream.io/ | |
| # Copy this to Dockerfile on a fresh rails app. Deploy to fly.io or any other container engine. | |
| # | |
| # try locally: docker build . -t rails && docker run -p3000:3000 -it rails | |
| # | |
| # in production you might want to map /data to somewhere on the host, | |
| # but you don't have to! | |
| # | |
| FROM ruby:3.0.2 |
| # set ruby/rails version | |
| export DOCKER_RAILS_VERSION="7.0.1" | |
| export DOCKER_RUBY_VERSION="3.1.0" | |
| export RAILS_PROJECT_NAME="rails7" | |
| # create folder for the project and add Gemfile with necessary rails version | |
| mkdir "$RAILS_PROJECT_NAME" | |
| cd "$RAILS_PROJECT_NAME" | |
| echo "ruby '$DOCKER_RUBY_VERSION' | |
| source 'https://rubygems.org' | |
| gem 'rails', '$DOCKER_RAILS_VERSION'" > Gemfile |