Microwave Pie
Browse documentation

🧭 Start Here

Blackcap Overview ✨ Blackcap Feature Catalog 🧱 Technology, Administration, and Reliability Installation First Run

🚀 Deploy Blackcap

Platform Stacks and Raspberry Pi Hardware Raspberry Pi Deployment Raspberry Pi Client Services GCP Deployment Packaged Blackcap deployment Application Updates Blackcap Release Notes Environment Variables and Secrets Reverse Proxy and TLS Background Jobs and Schedules

🛠️ Administer Blackcap

Organizations Users, Permissions, and Authentication Configuration Workspace Backups and Restore Database Administration Regression Testing Performance and Job Status Audit, Access Activity, and Logging GeoIP and Access Location Data Retention and Purge Support Chat Administration Support Requests API Tester and Postman Instance Reporting Microwave Pie licensing for Blackcap Microwave Pie licensing for Blackcap

🍽️ Use Recipes

Recipes and the Recipe Library Recipe Import and Discovery Recipe Editing and Cache Artifacts Recipe Sharing Social Recipe Import AI Recipe Image Generation

📅 Plan Meals

Meal Planner

🛒 Use Shopping Lists

Shopping Lists and Shop a List External and Household Shopping 🧩 Chrome Extension Shop With

🧺 Manage Kitchen Inventory

🧺 Kitchen Inventory

🖥️ Use Displays

Displays and Connections Assigning and Scheduling Display Content Remote Pi Client E-Ink Rendering Menu Refresh and Rendering Noun Project Footer Images

🧑‍🍳 Cook with Let’s Cook

🧑‍🍳 Let’s Cook 🧑‍🍳 Let’s Cook Controls and Timers

🤖 Use and Administer AI

🤖 AI in Blackcap 🤖 AI Providers and Connections 🤖 AI Seeds and Usage Support Chat

🧩 Use the Chrome Extension

🧩 Blackcap Chrome Extension 🧩 Chrome Extension Recipe Capture 🧩 Chrome Extension Shop With 🧩 Chrome Extension Release and Privacy

🎮 Play Games

🎮 Games and Trivia

🔌 Integrations

Email Integration Cloud Storage Integrations Voice Assistants Shop With Integrations Authentication Providers

⚙️ Develop Blackcap

Application Architecture Database Service and Data Access SQLite and PostgreSQL Database Migrations Background Job Architecture Testing API Architecture Security and Organization Scoping UI, Icons, and Documentation Assets Blackcap-Safe Emoji Support Chat Architecture Extending Support Chat Support Chat Model Benchmark Documentation Standards Terminology

⚠️ Troubleshoot Blackcap

⚠️ Troubleshooting Licensing Troubleshooting Deployment Troubleshooting Display Troubleshooting Recipe Import Troubleshooting 🤖 AI Troubleshooting Backup Troubleshooting Database Troubleshooting Diagnostic Organization Clones Support Chat

Blackcap Release Notes

Blackcap release notes summarize meaningful customer- and System Admin-facing changes in intentionally published releases. They are maintained as part of Blackcap's canonical documentation and are written deliberately after a substantial body of work is ready to communicate.

Release notes are not generated automatically from Git commits, development conversations, or raw issue lists. A release may ship without a published release-note entry while Blackcap remains under active alpha development. The presence or absence of release notes never controls update eligibility, package validation, installation, or rollback.

Release-note structure

When a release note is published, use the Blackcap application version as the primary identity and include the seven-character Git SHA when release provenance is known:

## vX.Y.Z (abcdef1)

The full Git SHA may be included once in release metadata when technical traceability is useful. Do not repeat it on every change item.

Use only the sections that contain meaningful information:

  • New — newly available user or administrator capabilities.
  • Improved — meaningful usability, performance, reliability, or workflow improvements.
  • Fixed — defects corrected in the release that are useful for users or administrators to know about.
  • Security — relevant security hardening or security-impacting fixes that are appropriate to disclose.
  • Deployment / Upgrade Notes — manual actions, compatibility considerations, migrations, or operational details that matter when moving to the release.
  • Known Issues — important limitations that remain in the release.

Keep entries concise and outcome-focused. Internal refactors, test-only changes, generated-file changes, and implementation details normally belong in development history rather than customer release notes.

Publishing workflow

At the end of a substantial Blackcap improvement cycle:

  1. Decide whether the accumulated changes are meaningful enough to publish as a release note.
  2. Confirm the version and exact release Git SHA that the note describes.
  3. Summarize the user-visible and operational changes rather than copying commit messages.
  4. Add only the applicable sections from the structure above.
  5. Call out any deployment action or known issue that a System Admin needs before applying the release.
  6. Keep older published entries unchanged except for factual corrections.

The System → Blackcap Updates panel links to this canonical page. When version-specific release entries begin to be published, their headings provide stable destinations that can be referenced directly without tying documentation to temporary package artifacts.

Release entry template

Use this template when the first deliberate release note is ready to publish:

## vX.Y.Z (abcdef1)

**Released:** YYYY-MM-DD  
**Full Git SHA:** `<40-character SHA>`

### New
- ...

### Improved
- ...

### Fixed
- ...

### Security
- ...

### Deployment / Upgrade Notes
- ...

### Known Issues
- ...

Remove any empty section before publishing. The release date and full SHA are optional when they are not useful for the intended audience.

Published releases

No deliberate Blackcap release-note entries have been published yet. This section will begin when a release is intentionally selected for customer-facing notes.

On this page