architecture-contract

Document the architecture contract for the Cambridge Beer Festival Flutter app.

2|3|Updated Nov 28, 2025
One-click install
npx skills add https://github.com/richardthe3rd/cambridge-beer-festival-app --skill architecture-contract
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-contract
Source: https://github.com/richardthe3rd/cambridge-beer-festival-app/tree/main/.claude/skills/architecture-contract
Command: npx skills add https://github.com/richardthe3rd/cambridge-beer-festival-app --skill architecture-contract

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Modifying the Cambridge Beer Festival Flutter app risks breaking enforced layer boundaries, core invariants, or persistence contracts if you lack access to the definitive, up-to-date architecture rules. This skill eliminates that risk by providing the complete, verified architecture contract for the app, so you can make changes confidently without re-discovering hard-won rules from past incidents.

Core Features & Use Cases

  • Layer Contract Reference: Clear definition of allowed and forbidden actions for every layer (UI, BeerProvider, domain controllers, repositories, services, models) to prevent cross-layer violations.
  • Enforced Invariants Guide: Documentation of all 11 code-level invariants with exact file:line citations and the historical incident each was designed to fix, so you understand the "why" behind every rule.
  • Storage & Persistence Rules: Complete guidance on UserDataStore schema versioning, additive vs breaking field change requirements, PreferenceKeys pinning, and legacy migration patterns to avoid data loss for existing users.
  • Extension Playbook: Step-by-step rules for adding new screens, models, services, sort options, and personal state fields that comply with the app's architecture.
  • Known Weak Points Catalog: List of currently open, tracked limitations so you don't waste time re-discovering them as new bugs.

Use this skill before adding any code to lib/providers/, lib/domain/, lib/services/, or lib/models/, or when responding to a code review comment that claims a layer boundary was crossed.

Quick Start

Load this skill before modifying any code in the app's core domain, provider, service, or model directories to ensure your changes align with the app's enforced architecture rules and avoid breaking core functionality.

Frequently Asked Questions about architecture-contract

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent Flutter app architecture layer boundary violations when modifying code?

To prevent Flutter app architecture violations, reference a definitive layer contract that defines allowed and forbidden actions for every layer including UI, providers, domain controllers, repositories, services, and models.

What are code invariants in state management and why are they enforced?

Code invariants in state management are enforced rules tied to historical incidents. Documenting all 11 invariants with exact file citations ensures developers understand the incident context behind each requirement to prevent regressions.

How do I safely handle schema migration and PreferenceKeys pinning in Flutter storage?

Handle schema migration safely by following UserDataStore versioning rules, distinguishing between additive versus breaking field changes, and pinning PreferenceKeys to avoid data loss for existing users during legacy migrations.

What is the best way to add new screens and models to a Flutter app without breaking architecture?

The best way to add screens and models without breaking architecture is to follow an extension playbook providing step-by-step compliance rules for adding services, sort options, and personal state fields to the app.

Why does code review flag cross-layer violations in my Flutter domain controllers?

Code review flags cross-layer violations in domain controllers because modifications bypassed the architecture contract. Load the definitive rules before modifying files in lib/providers, lib/domain, or lib/services to ensure compliance.

Are there known weak points or limitations in this app architecture I should avoid?

Known weak points in the app architecture are cataloged as tracked limitations. Reviewing this list prevents wasting time re-discovering open issues as new bugs during code modifications and state management updates.