mir-backend-python-flask

Solid

Make It Right (Flask module). Flask 3.1 + Werkzeug 3.1 specific reliability augmentation. Use alongside the mir-backend skill when the target stack is Flask — it carries the mechanical footguns that the framework-agnostic skill deliberately omits: app/request context misuse (current_app/request/g outside a context, background threads, Celery tasks), missing input validation and object-level authorization, SQLAlchemy session scoping and teardown, the app-factory pattern and circular imports, offloading heavy work to Celery/RQ, Flask 3.1 config safety (SECRET_KEY_FALLBACKS key rotation, TRUSTED_HOSTS after the SERVER_NAME behaviour change, MAX_CONTENT_LENGTH / MAX_FORM_MEMORY_SIZE / MAX_FORM_PARTS, debug-mode RCE), Alembic migration safety via Flask-Migrate, and Flask's own 2026 advisories. TRIGGER only when the Python backend stack is Flask — building, reviewing, or debugging a Flask route, blueprint, extension, SQLAlchemy session, or Flask-Migrate revision. Always loads TOGETHER WITH mir-backend (the gates) a

API & Backend 15 stars 0 forks Updated 1 weeks ago Apache-2.0

Install

View on GitHub

Quality Score: 81/100

Stars 20%
40
Recency 20%
90
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# /mir-backend-python-flask · Make It Right (Flask) Bottom tier of the chain: `mir-backend` (generic gates) → `mir-backend-python` (CPython runtime model) → **this** (Flask library mechanics). Run the gates first; load the Python runtime tier for the concurrency/process model; reach for *this* at Gate 5 (design mechanics), Gate 6 (implementation), and Gate 7 review. **Runtime-level concerns (GIL, async-vs-sync, blocking the event loop, fork-safe pools, cold start) live in `mir-backend-python` — not here.** **Stack assumed**, versions verified 13 Aug 2026: Flask **3.1.3** (released 18 Feb 2026; requires Python ≥3.9) · Werkzeug **3.1.8** · Flask-SQLAlchemy over SQLAlchemy **2.0.52** · PostgreSQL · Flask-Migrate / Alembic **1.19.1** · Celery or RQ for background work. If the project uses bare SQLAlchemy with a `scoped_session` instead of Flask-SQLAlchemy, apply the session-scoping rules directly — the pattern is the same, the scaffold differs. **Flask 3.1 changed `SERVER_NAME` semantics and added several limit settings** — see item 6; a codebase written against 3.0 has a real gap. ## The Flask footguns AI walks into most These are the stack-specific cousins of the failure-mode catalog. Each is something Flask code gets wrong even when the *logic* is right. ### 1. App and request context — the three magic proxies and where they die `current_app`, `request`, and `g` are context-local proxies that only resolve inside an active application or request context. Using them at imp...

Details

Author
anantbhandarkar
Repository
anantbhandarkar/make-it-right
Created
3 months ago
Last Updated
1 weeks ago
Language
Python
License
Apache-2.0

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

API & Backend Solid

mir-backend-python-fastapi

Make It Right (FastAPI module). FastAPI + Starlette + Async SQLAlchemy 2.0 + Postgres + Alembic + Redis specific reliability augmentation. Use alongside the mir-backend skill when the target stack is FastAPI — it carries the mechanical footguns that the framework-agnostic skill deliberately omits: async session lifecycle and scope, engine creation in lifespan (on_event is deprecated), Pydantic v2 validation boundaries, Annotated[...]-based Depends() auth and object-level authorization, BackgroundTasks vs a real queue, async N+1 with selectinload, greenlet/sync-driver-in-async traps, Starlette threadpool saturation, Alembic migration safety on populated tables, Redis idempotency/locking patterns, and the 2026 Starlette advisory set (Host-header path poisoning, form-limit bypass, StaticFiles UNC). TRIGGER only when the Python backend stack is FastAPI — building, reviewing, or debugging a FastAPI endpoint, dependency, Starlette middleware, SQLAlchemy session, or Alembic migration. Always loads TOGETHER WITH mir-

15 Updated 1 weeks ago
anantbhandarkar
AI & Automation Solid

mir-backend-python

Make It Right (Python runtime tier). CPython runtime reliability footguns that are shared across EVERY Python backend framework (FastAPI, Django, Flask, Celery) — distinct from the generic backend gates and from any one framework's mechanics. Covers: the GIL and the free-threaded build (PEP 703/779, officially supported since 3.14 but not the default), async-vs-sync 'coloring', blocking the event loop, choosing asyncio vs threads vs multiprocessing vs subinterpreters vs a worker queue, fork-safety of connection pools and the 3.14 forkserver default change, lazy annotations (PEP 649/749), serverless cold starts, dropped-task exceptions, and runtime-level security (unsafe deserialization, archive extraction, shell arguments, SSRF, packaging supply chain). TRIGGER when the backend runtime is Python — sits between mir-backend (generic) and the framework module (e.g. mir-backend-python-fastapi). SKIP for Node/JVM/Go/Rust/.NET/Ruby/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-l

15 Updated 1 weeks ago
anantbhandarkar
API & Backend Solid

mir-backend-python-django

Make It Right (Django module). Django 6.1 / 5.2 LTS + Django REST Framework specific reliability augmentation. Use alongside the mir-backend skill when the target stack is Django — it carries the mechanical footguns that the framework-agnostic skill deliberately omits: ORM N+1 with select_related/prefetch_related and the new QuerySet.fetch_mode() (FETCH_PEERS / FETCH_RAISE), queryset laziness and result caching, migration safety on populated tables (lock_timeout, AddIndexConcurrently, db_default), transaction.atomic() and on_commit() boundaries, mass assignment through ModelForm and DRF serializers, async views and the async ORM (transactions do NOT work in async; CONN_MAX_AGE must be off), the built-in django.tasks background framework added in 6.0, signal side-effect traps, and Django's own 2026 security advisories. TRIGGER only when the Python backend stack is Django — building, reviewing, or debugging a Django view, model, serializer, migration, task, or admin. Always loads TOGETHER WITH mir-backend (the

15 Updated 1 weeks ago
anantbhandarkar