Engineering Craft
Engineering Craft, Patterns & Coding Standards
Quality & Formatting Mandate
This document outlines the strict software engineering patterns, linting configurations, and quality metrics required for all contributions to the Level 4 HMIS codebase. It highlights native Mermaid implementations for flowcharts, ERDs, and code documentation.
1. Automated Code Style & Quality Enforcement
To prevent technical debt and maintain uniform readability across a multi-proficient development team, the codebase enforces strict, automated linting pipelines before any code is committed.
1.1 Python Backend Linting Strategy (Ruff)
We replace traditional formatting toolchains (flake8, black, isort) with Ruff. It achieves near-instantaneous linting and formatting execution speeds.
1.2 Frontend Code Quality Standards (ESLint & Prettier)
The Vue/Nuxt layers use modern flat configs to maintain type safety and component template consistency:
2. Mandatory Documentation Protocol: Native Mermaid Integration
All structural components, entity relationship diagrams (ERDs), module boundaries, and execution logic lifecycles must be visually documented.
Mandatory Rule: Do not use raster images, screenshots, or binary attachments for diagrams. All system visual representations must use native Mermaid code blocks directly inside the Markdown files. This ensures schemas remain searchable, trackable via Git diffs, and straightforward for any engineer to update.
2.1 Sample Domain Entity Relationship Diagram Blueprint
When proposing changes to a database module, submit a native Mermaid ERD alongside the migration files:
3. Core Architectural Implementation Patterns
The HMIS avoids leaky business logic inside views or direct fat database models by enforcing a clean, transactional service pattern layer.
3.1 The Transactional Service Pattern (Backend)
All mutations, external integrations, and heavy workflow calculations must reside within specialized service files (services.py). Views must only serve as HTTP entry/exit validation barriers.
4. Frontend Component & Composable Design Principles
To maximize memory performance and reuse common patterns across thin clients, the frontend structure follows a composable-driven architecture.
4.1 Strict TypeScript Composition Profile (Frontend)
Avoid options API structures or untyped states. Use clear, descriptive custom composables to handle cross-cutting features:
Document Verification Block
Author: Ian Wataka - Backend EngineerTarget Scope: Monorepo Code Standards & Pattern Quality