peer · zach

## Explicit Observations

[2026-05-16 17:47:23] zach proposes migrating projects from pip/poetry/pipenv to uv before falling back to legacy tools
[2026-05-16 17:47:23] zach uses `uv init` to create new projects
[2026-05-16 17:47:23] zach uses `uv sync` to sync from lockfile in a uv-managed project
[2026-05-16 17:47:23] zach only uses REST APIs and does not use GraphQL
[2026-05-16 17:47:23] zach always uses `uv` for Python package management and explicitly avoids pip, pip3, pip-tools, pipenv, and poetry
[2026-05-16 17:47:23] zach uses MySQL when the client has a preference
[2026-05-16 17:47:23] zach uses PostgreSQL for production databases
[2026-05-16 17:47:23] zach always uses pnpm as the package manager
[2026-05-16 17:47:23] zach uses `uv venv` to create virtual environments
[2026-05-16 17:47:23] zach uses SQLite for prototypes
[2026-05-16 17:47:23] zach always uses OpenAPI/Swagger documentation
[2026-05-16 17:47:23] zach uses `uv pip install` or `uv add` to install packages in a uv-managed project
[2026-05-16 17:47:23] zach prefers Flask or FastAPI (Python) for the backend

## Deductive Observations

[2026-05-16 19:00:23] Zach practices self-hosted infrastructure management, operating personal VPS, Coolify instance, and Docker containers without managed CI/CD pipelines.
   Premises:
   - Has personal VPS at 72.61.17.83 with SSH host alias
   - Personal Coolify instance at coolify.lagden.dev
   - Explicitly avoids Kubernetes and CI/CD pipelines

[2026-05-16 19:00:23] Zach maintains comprehensive observability practices using Sentry for all applications and structured JSON logging with strict no-secrets policy.
   Premises:
   - Uses Sentry for all observability
   - Uses structured JSON logging
   - Never logs secrets

[2026-05-16 19:00:23] CONTRADICTION: Zach has conflicting guidance on code comments. The Critical Rules state 'Never write comments in code', but the Code Style document explicitly states 'Comments explain WHY not WHAT' and defines a TODO format using comments. These statements are mutually exclusive.
   Premises:
   - Critical Rules: 'Never write comments in code'
   - Code Style: 'Comments explain WHY not WHAT' and '// TODO(zach): reason' format

[2026-05-16 19:00:23] Zach is likely based in the United Kingdom, evidenced by his use of .uk domain names (zachlagden.uk, digigrow.uk, wiki.admin.digigrow.uk).
   Premises:
   - Owns zachlagden.uk domain
   - DigiGrow infrastructure uses digigrow.uk domain

[2026-05-16 19:00:23] Zach is a full-stack developer proficient in TypeScript/JavaScript (Next.js, React, Tailwind) and Python (Flask/FastAPI) ecosystems.
   Premises:
   - Default frontend is Next.js with Tailwind CSS
   - Backend defaults to Flask or FastAPI (Python)
   - Always uses pnpm for JS/TS, uv for Python

[2026-05-16 19:00:23] Zach follows modern API-first architecture principles with REST-only preference, OpenAPI documentation, and SQL-first database access patterns.
   Premises:
   - Only uses REST APIs, does not use GraphQL
   - Always uses OpenAPI/Swagger documentation
   - Defaults to raw SQL with Alembic for migrations
   - Uses parameterized queries to prevent SQL injection

[2026-05-16 19:00:23] Zach prioritizes code readability and maintainability through self-imposed constraints: descriptive naming, functions under 50 lines, components under 300 lines, explicit error handling.
   Premises:
   - Prefers descriptive names in code
   - Values readability over cleverness
   - Keeps functions under 50 lines
   - Keeps components small and focused at under 300 lines
   - Prefers explicit error handling, never silently fails


## Inductive Observations

 **Pattern** [medium]: Zach mandates aggressive skill composition - when tasks match multiple skill groups, ALL relevant skills must be invoked rather than selecting a few. Uses language like 'invoke ALL skills', 'never rationalize skipping', 'even 1% chance a skill applies'
   **Type**: behavior
   **Sources**:
   - Skill Usage section in startup: 'invoke EVERY design skill + EVERY copy skill + CRO + animation skills'
   - Skill Composition Rules: 'IMPORTANT: Before starting ANY task, you MUST evaluate which skills are relevant and invoke ALL of them. Never use just 1-2 skills when multiple apply'

 **Pattern** [medium]: When encountering legacy tools like pip/poetry/pipenv, Zach proposes migrating to modern alternatives (uv) rather than falling back to legacy tooling
   **Type**: tendency
   **Sources**:
   - Observation: 'zach proposes migrating projects from pip/poetry/pipenv to uv before falling back to legacy tools'
   - Tech Stack: 'If a project still uses pip/poetry/pipenv, propose migrating to uv first — don't fall back to the legacy tool'

 **Pattern** [medium]: Zach's pull request requirements emphasize justification over description - PRs must include 'changes and why' not just what changed, and commit messages require lowercase type, imperative mood
   **Type**: behavior
   **Sources**:
   - Git Workflow: 'Include description of changes and why'
   - Git Workflow: 'Lowercase type, imperative mood, under 72 characters, and no full stop'

 **Pattern** [medium]: Zach maintains comprehensive, formalized documentation across multiple instruction files (git-workflow.md, tech-stack.md, code-style.md, security.md) with explicit rules and conventions
   **Type**: personality
   **Sources**:
   - Observation: zach's tech stack is documented in ~/.claude/instructions/tech-stack.md
   - Observation: zach's code style guidelines are documented in ~/.claude/instructions/code-style.md
   - Observation: zach's security guidelines are documented in ~/.claude/instructions/security.md

 **Pattern** [medium]: Zach follows pragmatic tool selection based on context - Express.js only for dead simple APIs, Rust ONLY for performance-critical workers (never web servers), MySQL when client has preference
   **Type**: preference
   **Sources**:
   - Tech Stack: 'Express.js only for dead simple APIs'
   - Tech Stack: 'Rust ONLY for performance-critical workers, never for web servers'
   - Observation: 'zach uses MySQL when the client has a preference'