feat: add Fizzy template blueprint

[adryserage]

Summary

Adds Fizzy, a Kanban-style issue and idea tracker by 37signals (Basecamp).

Changes

• \�lueprints/fizzy/docker-compose.yml\ — Single-service setup with SQLite storage
• \�lueprints/fizzy/template.toml\ — SMTP, VAPID keys, Rails config
• \�lueprints/fizzy/fizzy.svg\ — Logo
• \meta.json\ — Added Fizzy entry (alphabetical order)

Context

Clean resubmission of #581 (closed for inactivity). This PR only contains the Fizzy blueprint — no CI/workflow changes.

Docker Compose

• \ghcr.io/basecamp/fizzy:main\
• Expose port 3000 (no \ports:\ — uses Traefik)
• SQLite volume for persistence
• SMTP for emails, VAPID for push notifications

Greptile Summary

Adds Fizzy, a Kanban-style issue and idea tracker by 37signals (Basecamp), as a new template blueprint.

Key changes:

• New blueprint with single-service Docker Compose setup using SQLite for persistence
• Template configuration with SMTP for emails and VAPID keys for push notifications
• Proper logo and metadata integration

Issues found:

• Critical: Service name in docker-compose.yml is web but must be fizzy to match the blueprint folder name (per AGENTS.md line 46)
• Required: Missing version: "3.8" declaration in docker-compose.yml (per AGENTS.md line 149)
• Required: Service name in template.toml must also be updated to fizzy to match
• Formatting: Extra indentation on opening brace in meta.json entry

These are straightforward fixes that maintain consistency with project conventions.

Confidence Score: 3/5

• Safe to merge after fixing service naming convention violations
• The template is well-structured and follows most conventions correctly, but has critical naming convention violations that will cause deployment issues. Service name must match blueprint folder name (fizzy not web) in both docker-compose.yml and template.toml, missing required version: "3.8" declaration, and minor formatting issue in meta.json. Once these syntax issues are resolved, the template will be production-ready.
• blueprints/fizzy/docker-compose.yml and blueprints/fizzy/template.toml need service name corrections, meta.json needs indentation fix

_{Last reviewed commit: f1cd2ae}

Context used:

• Context from dashboard - AGENTS.md (source)

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Name	Status	Preview	Last Commit
templates	✅ Ready (View Log)	Visit Preview	d66c0e2

[greptile-apps]

_{4 files reviewed, 4 comments}

_{Edit Code Review Agent Settings | Greptile}

[Copilot]

Pull request overview

Adds a new Dokploy blueprint for deploying Fizzy (Basecamp/37signals) and registers it in the template catalog.

Changes:

• Added blueprints/fizzy/docker-compose.yml for a single-service Fizzy deployment with persistent storage.
• Added blueprints/fizzy/template.toml with Dokploy variables, env wiring, and domain mapping.
• Added Fizzy logo and a new meta.json entry for template discovery.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 4 comments.

File	Description
meta.json	Adds the Fizzy template metadata (id/name/version/links/tags).
blueprints/fizzy/template.toml	Defines variables and Dokploy config (env + domain mapping to the web service).
blueprints/fizzy/fizzy.svg	Adds the Fizzy logo used by the template listing.
blueprints/fizzy/docker-compose.yml	Introduces the Fizzy Compose definition (service + env + volume + expose).

[adryserage]

@copilot open a new pull request to apply changes based on the comments in this thread

[Copilot]

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated 2 comments.

[Copilot]

The version field uses "main" which corresponds to the Docker image tag. According to project conventions, versions should be pinned to specific releases rather than tracking branch names like "main" to avoid unexpected breaking changes. While this matches the docker-compose.yml image tag, consider using a specific version number when Fizzy releases stable versions.

[Copilot]

The Docker image uses the :main tag which is a moving target similar to :latest. According to the project conventions, images should be pinned to specific versions to prevent templates from breaking when upstream images change unexpectedly. While :main is used in some other blueprints (e.g., aptabase, windmill), the recommended practice is to use a specific version tag or commit SHA. Consider pinning to a specific release version if available, or at minimum document that this template tracks the main branch and may experience breaking changes.