# =============================================================================
# COMPETENCY RECORD - Cedric Ancellin's demonstrated engineering skills and
# experience. Third-party technologies and vendors are named as the concrete
# skill surface. Professional background / track record.
# =============================================================================

# ============================================================
# BACKEND & PLATFORM ENGINEERING - COMPETENCY RECORD
# ============================================================
# Core Purpose:
#   Demonstrated experience building and operating a large,
#   framework-free PHP backend at scale: the database
#   abstraction layer, ID/encoding schemes, soft-delete and
#   audit patterns, schema-guarding, and the platform
#   primitives every other domain depends on.
# ============================================================

summary: >
  Built a ~42,000-file, framework-free PHP backend from first
  principles, including a hand-rolled database abstraction
  layer, ID-generation and encoding schemes, schema-introspecting
  guards, soft-delete + audit conventions, and the shared system
  primitives (sanitization, error handling, caching, encoding)
  that the entire platform is built on.


# ==================================================================
# 1. LARGE FRAMEWORK-FREE MONOLITH
# ==================================================================

monolith:
  description: >
    Designed and sustained a very large PHP codebase without a
    web framework or ORM, relying instead on explicit, uniform
    conventions and a shared primitive library.
  characteristics:
    - "~42,000 PHP files; ~41,500 function/class declarations."
    - "~113 business-logic domain modules behind a thin handler layer."
    - "Explicit include-based module loading with a consistent relative-path discipline."
    - "A ~5,600-file shared business-logic library reused across every API version."
  engineering_judgment:
    - "Chose convention + primitives over framework magic to keep a large team productive and the hot path predictable."
    - "Kept handlers thin and pushed all reusable logic into the shared library."


# ==================================================================
# 2. DATABASE ABSTRACTION LAYER (HAND-BUILT, ORM-LESS)
# ==================================================================

data_layer:
  description: >
    Engineered a raw-SQL abstraction layer (~2,300 lines) that
    provides safety, routing, and audit without an ORM.
  features:
    connection_routing: "Database-code convention {schema}_{tier} resolves to per-environment config; primary / read-replica / analytics-replica tiers."
    connection_pooling: "Persistent connections cached per database code within a request."
    crud_family: "A uniform get/insert/update/delete/restore/value function family passed a shared context object."
    schema_guard: "First-write column introspection auto-filters unknown fields and auto-detects the primary key and JSON columns (skipping double-escaping on JSON payloads)."
    query_modes: "Echo / trace / verbose / dry-run modes for safe debugging in non-production."
    multi_db_transactions: "Cross-database transactions with named savepoints (start / commit / rollback per identifier)."


# ==================================================================
# 3. SOFT-DELETE, STATUS, AND AUDIT CONVENTIONS
# ==================================================================

data_integrity_conventions:
  description: >
    Established platform-wide conventions that make destructive
    operations safe and every mutation auditable.
  soft_delete: "Rows are never physically dropped, a status column marks active vs. deleted vs. inactive; delete and restore are status toggles."
  status_state_machines: "Multi-field status precedence (current > cancel > operate > reserve) supports complex booking lifecycles without ambiguous state."
  audit_stamping: "Every insert/update stamps creator and modifier identity from the request context."
  entity_tracking: "A dedicated entity-tracking scheme pre-allocates platform-wide unique IDs before domain rows are written, enabling cross-domain dedup and reconciliation (parent/uncle linkage for multi-level relationships)."


# ==================================================================
# 4. ID GENERATION & ENCODING
# ==================================================================

identifiers:
  description: >
    Designed the platform's identifier and encoding schemes to
    keep internal keys off the wire and IDs collision-free at
    scale.
  schemes:
    - "Base-26 alphanumeric public codes with a modulus check character to prevent tampering, using arbitrary-precision math for IDs beyond native integer range."
    - "Typed API keys: the leading digit encodes key type; the remainder encodes the record ID."
    - "Encrypted composite pointers that pack multiple internal IDs (e.g., location + item + date) into a single opaque token for external channels."
    - "Trigger-aware ID assignment: defers to database triggers when present, otherwise composes server + sequence IDs."


# ==================================================================
# 5. PLATFORM PRIMITIVES
# ==================================================================

primitives:
  description: >
    Built the shared system layer that every domain relies on.
  modules:
    sanitization: "Global input cleanup with HTML-entity encoding on the way in and decode on the way out; SQL-safety applied inside the write path."
    error_handling: "Custom error handler with per-datastore failure handlers and environment-gated verbosity."
    caching_helpers: "Cache get/set/increment/hash/TTL helpers over the external cache tier."
    encoding_helpers: "Bidirectional numeric↔alpha, key↔ID, and public-code generation utilities."
    response_builder: "A single response structure serialized to any supported wire format."


# ==================================================================
# 6. BREADTH OF DOMAINS IMPLEMENTED
# ==================================================================

domain_breadth:
  description: >
    Implemented business logic across a wide functional surface,
    all on the shared primitives above.
  domains:
    - "Reservations, parties, guest lists, waitlists, and seating."
    - "Inventory, catalog, stock allocation, and availability."
    - "Checkout, payments, refunds, comps, and reconciliation."
    - "CRM: profiles, tagging, import/export, entity reconciliation."
    - "Memberships / loyalty tiers and benefits."
    - "Notifications and multi-channel messaging."
    - "Point-of-sale order entry and shift/close operations."
    - "Admin, access control, and platform superuser tooling."
    - "Document generation, QR codes, and a file/image server."
  cross_reference:
    $ref: "https://zc8.com/competencies/03_commerce_inventory_engine"


# ==================================================================
# 7. A SECOND BACKEND PARADIGM - NESTJS / TYPEORM / POSTGRESQL
# ==================================================================

modern_backend:
  description: >
    Beyond the framework-free PHP monolith, architected a separate
    production backend on a modern, opinionated TypeScript stack -
    proving the same platform-engineering instincts transfer across
    paradigms.
  stack:
    - "NestJS 11 (modular DI, controllers / providers / guards) on Node.js 20+, TypeScript 5.7."
    - "TypeORM 0.3 over PostgreSQL; entities extend a shared BaseEntity; class-validator / class-transformer DTOs."
    - "JWT auth via @nestjs/jwt + passport-jwt guards; bcrypt for secrets; @nestjs/schedule for cron sync jobs."
    - "Versioned TypeORM migrations rather than ad-hoc schema drift."
  conventions_carried_across:
    - "The same soft-delete + state-machine discipline as the PHP platform, a single integer state field (active / redeemed / soft-deleted / inactive) rather than physical deletes."
    - "Time-sortable UUIDv7 primary keys; snake_case columns mapped to camelCase in code; audit timestamps on every entity."
    - "Thin controllers over a service layer, the same 'keep handlers thin, push logic down' instinct as the monolith."
  engineering_judgment: "Chose a batteries-included framework here (vs. the deliberately framework-free monolith) because a small / AI-executed team benefits from strong conventions and guard-rails baked in. See COMP-21 for the surrounding distributed architecture."