cfsa-antigravity 2.19.0 → 2.19.2

package/template/.claude/skills/concise-planning/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: concise-planning
+description: "Use when a user asks for a plan for a coding task, to generate a clear, actionable, and atomic checklist."
+version: 2.0.0
+source: self
+date_added: "2026-02-27"
+date_rewritten: "2026-03-14"
+---
+
+# Concise Planning
+
+Generate focused, actionable implementation plans that eliminate ambiguity and prevent scope creep.
+
+## When to Use
+
+- User asks "how should I approach this?" or "can you make a plan for X?"
+- Task involves multiple files or components
+- Work spans more than ~3 logical steps
+- You need to communicate a proposed sequence before executing
+
+## When NOT to Use
+
+- Task is a single-step operation (just do it)
+- User gave an explicit command with clear intent (just execute)
+- During `/plan-phase` or `/implement-slice` (those have their own planning structure)
+
+## Workflow
+
+### 1. Scan Context (30 seconds, not 5 minutes)
+
+Read only what's necessary:
+- **Project structure** — `ls` the relevant directories
+- **Existing patterns** — check one similar file for conventions
+- **Constraints** — look for test frameworks, linters, type systems in use
+
+Do NOT read every file in the project. Do NOT generate a 500-line analysis. Scan, not study.
+
+### 2. Ask or Assume
+
+- **0 questions** if the task is clear and you have enough context
+- **1 question max** if there's a genuinely blocking ambiguity
+- **Never more than 2** — if you need more, you don't understand the codebase well enough. Go read more code instead of asking.
+
+For non-blocking unknowns, state your assumption:
+> "Assuming we want this as a new utility in `lib/` rather than inline — will adjust if you prefer otherwise."
+
+### 3. Generate Plan
+
+Use this exact structure:
+
+```markdown
+## Approach
+
+[1-3 sentences: what you'll do and why this approach over alternatives]
+
+## Scope
+
+**In:**
+- [Specific deliverable 1]
+- [Specific deliverable 2]
+
+**Out:**
+- [Explicitly excluded item — prevents scope creep]
+
+## Steps
+
+1. [Verb] [specific target] — [why, if non-obvious]
+2. [Verb] [specific target]
+3. [Verb] [specific target]
+4. [Verb] [specific target]
+5. Validate: [specific validation command or check]
+
+## Assumptions
+
+- [Assumption 1 — what you decided without asking]
+```
+
+### Plan Quality Rules
+
+| Rule | Why |
+|------|-----|
+| **6-10 steps** | Fewer = too vague. More = over-planned. |
+| **Verb-first steps** | "Add", "Create", "Refactor", "Test" — not "The component should..." |
+| **Name files and functions** | "Add `validateEmail()` to `lib/validators.ts`" not "add validation" |
+| **One validation step minimum** | Every plan ends with proof it works |
+| **Explicit "Out" scope** | Prevents the plan from growing mid-execution |
+| **No nested sub-plans** | If a step needs sub-steps, it's too big — split it |
+
+### Anti-Patterns
+
+| Don't | Do |
+|-------|-----|
+| "Research best practices for X" | Just apply the best practice directly in a step |
+| "Consider whether to use A or B" | Pick one, state why, move on |
+| "Set up the project structure" | "Create `src/validators/` with `index.ts` and `email.ts`" |
+| "Write tests" | "Add tests for `validateEmail`: valid input, empty string, missing @, >254 chars" |
+| 20-step plan | 8-step plan with clear scope boundaries |
+| Plan that describes what might happen | Plan that describes what WILL happen |
+
+## Output Format
+
+Always present the plan in a markdown code block or as structured markdown. Never as prose paragraphs.
+
+After presenting the plan, ask one question:
+> "Ready to execute, or want to adjust anything?"
+
+Then execute on confirmation — don't re-plan.

package/template/.claude/skills/cross-layer-consistency/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: cross-layer-consistency
+description: Systematic methodology for verifying that IA, BE, and FE specification layers are mutually consistent. Covers coverage matrices, field mapping checks, error code propagation, access control consistency, and data contract drift detection.
+---
+
+# Cross-Layer Consistency
+
+This skill provides the systematic consistency verification pass run by `audit-ambiguity-execute`, `remediate-pipeline-execute`, `propagate-decision-scan`, and `evolve-feature-cascade`, and its output is a set of labeled consistency issues with layer attribution.
+
+## When to Use
+
+- After all three spec layers (IA, BE, FE) have at least one document written
+- As part of every audit, every remediation, every decision propagation, and every feature evolution cascade
+- As a standalone pre-gate check before advancing any pipeline stage
+
+## Instructions
+
+### 1. IA → BE Coverage Matrix
+
+Open `docs/plans/ia/index.md` to enumerate all IA shards. For each shard, read its data model and state transition sections. Then open `docs/plans/be/` and verify:
+
+- Every IA data model entity has a corresponding BE spec section describing its schema, storage contract, and CRUD operations.
+- Every IA state transition has a corresponding BE endpoint that drives it.
+- Every IA user action (described in the interactions section) has a corresponding API contract in the BE spec.
+
+Build a coverage table:
+
+| IA Shard | IA Section | BE Spec Section | Status |
+|----------|-----------|-----------------|--------|
+| [name]   | [section] | [BE section]    | ✅ / ❌ |
+
+Document each gap as:
+
+```
+COVERAGE GAP: IA shard [name] § [section] → no corresponding BE spec section found.
+```
+
+### 2. BE → FE Field Mapping Check
+
+For every BE endpoint documented in `docs/plans/be/`, enumerate all response fields. For each field, verify it appears in `docs/plans/fe/` — in a component prop definition, a display element, a table column, or an explicit "field not rendered" exclusion.
+
+Then for each FE component, verify every input prop maps to a BE request field.
+
+Build a mapping table:
+
+| BE Endpoint | Field | FE Spec Location | Status |
+|-------------|-------|-------------------|--------|
+| [endpoint]  | [field] | [FE location]   | ✅ / ❌ |
+
+Document each gap as:
+
+```
+MAPPING GAP: BE endpoint [name] field [field] → not referenced in FE spec.
+```
+
+### 3. Error Code Consistency Cross-Reference
+
+Build an error code table across layers: for every HTTP status code and application error type defined in BE specs, create a row. Then for each row, identify the FE spec location that handles it (error boundary, toast handler, inline error state, retry logic).
+
+| BE Endpoint | Error Code | FE Handler | FE Spec Location | Status |
+|-------------|-----------|------------|-------------------|--------|
+| [endpoint]  | [code]    | [handler]  | [location]        | ✅ / ❌ |
+
+Any BE error code with no corresponding FE entry is a gap. Document as:
+
+```
+CONSISTENCY ISSUE: BE § [endpoint] error [code] ↔ FE — no handling found — remediation: add [code] handler to [FE spec section].
+```
+
+### 4. Access Control Propagation Check
+
+For every access control rule defined in IA shards (role-resource-operation triplets), verify the rule appears in both:
+
+- **BE**: as a middleware guard, route-level permission check, or explicit authorization step in the endpoint contract.
+- **FE**: as a conditional render, route guard, or disabled state on the triggering UI element.
+
+A rule missing from either layer is a gap. Document as:
+
+```
+CONSISTENCY ISSUE: IA § [access control section] permission [role→resource:operation] ↔ [BE or FE] — not found — remediation: add guard to [target layer § section].
+```
+
+### 5. Data Contract Drift Detection
+
+When invoked in the context of a schema change (e.g., after `evolve-contract` or a `propagate-decision` run), scan all files under `docs/plans/` for references to the changed type, field name, or validation rule. Check for:
+
+- Field name string matches
+- Type annotation references
+- Validation rule references
+
+For each file that references the old definition and has not been updated, document as:
+
+```
+CONSISTENCY ISSUE: [source layer] § [section] ↔ [target file] § [section] — [field/type] changed in source but not reflected in target — remediation: update [target] to match [source].
+```
+
+### 6. Documenting Inconsistencies
+
+All consistency issues must be written using this exact format:
+
+```
+CONSISTENCY ISSUE: [source layer] § [section] ↔ [target layer] § [section] — [what is inconsistent] — [remediation: update [target] to match [source] OR raise for user decision]
+```
+
+- **Source layer** is the authoritative layer (the one that should not change).
+- **Target layer** is the one that needs updating.
+- When it is unclear which layer is authoritative, write `raise for user decision` as the remediation and present both versions to the user. Never silently pick one.
+
+## Anti-Patterns
+
+- **One-direction-only checking** — Checking only one direction of the matrix (IA→BE but not BE→IA). Coverage gaps exist in both directions.
+- **Skipping the error code table** — Skipping the error code table because "the FE will just show a generic error." Every BE error code must have an explicit FE handling specification.
+- **Treating access control propagation as optional** — Treating access control propagation as optional when the spec "looks simple." Missing FE route guards are a security gap, not a style preference.
+
+## Related Skills
+
+- **`resolve-ambiguity`** — Hand off to `resolve-ambiguity` when a consistency issue cannot be resolved by simply updating the target layer to match the source. Specifically: when both layers present plausible but conflicting definitions and it is unclear which is authoritative, or when the inconsistency reveals a gap that requires new information from the user. This skill detects *what is inconsistent*; `resolve-ambiguity` determines *what the correct answer should be* through its tiered information-gathering methodology.

package/template/.claude/skills/database-schema-design/SKILL.md

@@ -0,0 +1,205 @@
+---
+name: database-schema-design
+description: Design database schemas with normalization, relationships, and constraints. Use when creating new database schemas, designing tables, or planning data models for any database paradigm.
+---
+
+# Database Schema Design
+
+## Overview
+
+Design scalable, well-structured database schemas with proper relationships, constraints, and data types. This skill covers universal data modeling principles. For paradigm-specific patterns, see references.
+
+## When to Use
+
+- New database schema design
+- Data model planning
+- Relationship design (1:1, 1:N, N:N, graph edges)
+- Normalization or denormalization analysis
+- Constraint and validation planning
+- Performance optimization at schema level
+- Cross-store entity consistency
+
+## Paradigm-Specific References
+
+After reading the methodology below, read the reference matching your surface's Databases column in the surface stack map (`.agent/instructions/tech-stack.md`):
+
+| Paradigm | Reference | Example Stores |
+|----------|-----------|----------------|
+| Relational | `references/relational.md` | PostgreSQL, MySQL, SQLite |
+| Document | `references/document.md` | MongoDB, Firestore, CouchDB |
+| Graph | `references/graph.md` | SurrealDB, Neo4j, ArangoDB |
+| Key-Value | `references/key-value.md` | Redis, DynamoDB, Memcached |
+
+---
+
+## Universal Data Modeling Principles
+
+### 1. Entity Identification
+
+Start with the domain:
+1. **Identify nouns** — these become entities/tables/collections
+2. **Identify relationships** — how entities connect
+3. **Identify attributes** — what data each entity holds
+4. **Identify cardinality** — one-to-one, one-to-many, many-to-many
+
+### 2. Normalization vs Denormalization
+
+**Normalization** reduces data duplication at the cost of join complexity:
+- **1NF** — Eliminate repeating groups (no arrays/CSVs in a single field)
+- **2NF** — Remove partial dependencies (every non-key attribute depends on the WHOLE key)
+- **3NF** — Remove transitive dependencies (non-key attributes don't depend on each other)
+
+**Denormalization** trades storage for read performance:
+- Embed frequently co-read data together
+- Pre-compute aggregates for dashboards
+- Duplicate data intentionally (with consistency strategy)
+
+**Decision framework:**
+- Write-heavy, consistency-critical → normalize
+- Read-heavy, latency-sensitive → denormalize
+- Mixed → normalize core, denormalize read models
+
+### 3. Relationship Patterns
+
+| Pattern | Relational | Document | Graph |
+|---------|-----------|----------|-------|
+| **One-to-One** | Foreign key with UNIQUE | Embed subdocument | Edge with cardinality constraint |
+| **One-to-Many** | Foreign key on child | Embed array OR reference | Edge from parent to children |
+| **Many-to-Many** | Junction/join table | Array of references on both sides | Direct edges |
+| **Hierarchical** | Self-referencing FK | Nested documents | Recursive graph traversal |
+
+### 4. Access Pattern Design
+
+Schema design is driven by how data is **queried**, not just how it's structured:
+
+1. **List your read queries** — what does the UI need to display?
+2. **List your write queries** — what creates/updates data?
+3. **Design schema to serve the reads** — not the other way around
+4. **Index for query patterns** — not for every possible query
+
+### 5. Constraint Strategy
+
+Every schema must enforce:
+- **Required fields** — NOT NULL / required validators
+- **Uniqueness** — unique constraints on natural keys (email, SKU, slug)
+- **Referential integrity** — foreign keys, references, or application-level checks
+- **Domain constraints** — CHECK constraints, enums, value ranges
+- **Cascade behavior** — what happens when parent is deleted (CASCADE, SET NULL, RESTRICT)
+
+### 6. ID Strategy
+
+| Strategy | When to Use |
+|----------|-------------|
+| **UUID v4** | Default choice. No ordering, globally unique, no collision |
+| **UUID v7** | When you need time-sortable UUIDs (better index performance) |
+| **Auto-increment** | Simple cases, single-database, non-distributed |
+| **ULID** | Time-sortable, lexicographically sortable, URL-safe |
+| **Natural key** | When domain provides a unique identifier (ISBN, SSN) — use with caution |
+
+---
+
+## Schema Design Checklist
+
+- [ ] Identify entities and relationships
+- [ ] Choose ID strategy
+- [ ] Apply normalization rules (or consciously denormalize with rationale)
+- [ ] Define primary keys for all entities
+- [ ] Create foreign keys / references for relationships
+- [ ] Add constraints for data integrity
+- [ ] Select appropriate data types
+- [ ] Plan indexes for common queries
+- [ ] Design for scalability
+- [ ] Document entity purposes and relationships
+- [ ] Plan for schema evolution
+
+## Common Pitfalls
+
+❌ Don't skip normalization for convenience
+❌ Don't use unbounded text types for all string fields
+❌ Don't forget referential integrity constraints
+❌ Don't use mutable natural keys as primary keys
+❌ Don't store computed values without a cache invalidation strategy
+❌ Don't design schema without knowing query patterns
+
+✅ DO use UUIDs or equivalent for primary keys
+✅ DO normalize data unless you have a measured performance reason not to
+✅ DO add validation constraints at the schema level
+✅ DO index foreign keys and common query fields
+✅ DO use timestamps for audit trails
+
+---
+
+## Persistence Map Interview
+
+This interview runs during `/create-prd-stack` Sub-steps A–E. It maps every feature to its query types, then selects the right store for each query type.
+
+### Sub-step A — Feature-to-Query Table
+
+Walk through every major feature in `ideation-index.md` and ask: "What does this feature need to find, store, relate, and rank/search?"
+
+Build the following table:
+
+| Feature | Find | Store | Relate | Rank/Search |
+|---------|------|-------|--------|-------------|
+| (from ideation-index.md) | … | … | … | … |
+
+Present and confirm the table with the user before proceeding to Sub-step B.
+
+### Sub-step B — Registry-First Skill Search
+
+Before presenting any store options, read `.agent/skills/find-skills/SKILL.md` and run `npx skills find [query type or store name]` for each query type that appeared in the table.
+
+If the registry returns a skill, install it first. The bundled skill library is a fallback only.
+
+### Sub-step C — Store Selection Per Query Type
+
+Present store options only for query types that appeared in the table:
+
+- Skip `DATABASE_VECTOR` if no Rank/Search requirement appeared.
+- Skip `DATABASE_GRAPH` if no Relate requirement appeared.
+
+Use constraint-first per-axis flow: constraint questions → filter → present → confirm.
+
+### Sub-step D — Bootstrap Per Confirmed Store
+
+For each confirmed store, fire bootstrap with its specific sub-key:
+
+- e.g., `DATABASE_PRIMARY=PostgreSQL`, `DATABASE_VECTOR=Qdrant`
+- One bootstrap call per sub-key.
+- Each confirmation adds a database skill to the Databases column of the relevant surface row in the surface stack map.
+
+### Sub-step E — Write Persistence Map
+
+After all stores are confirmed, write to `docs/plans/architecture-draft.md` as a locked section titled `## Persistence Map`.
+
+Must include:
+- The feature-to-query table from Sub-step A
+- A mapping of each query type to its canonical store with rationale
+
+---
+
+## Cross-Store Entity Consistency Protocol
+
+### Triggering Rule
+
+This protocol runs for every entity that spans more than one store.
+
+### The 4 Questions
+
+For each cross-store entity, answer the following in order:
+
+1. **Canonical ID** — Single identifier tying representations together. Must be the primary store's UUID stored as a property in every other store — never the graph store's or vector store's internal ID.
+
+2. **Creation sequence** — Which store is written first. Recovery mechanism for partial write failures (Saga pattern, compensating transaction, or async retry queue — name which).
+
+3. **Deletion cascade** — Cleanup order, mechanism (application-layer sequential deletes, DB-level triggers, or background job — name which).
+
+4. **Read strategy** — Whether a read requires data from multiple stores. Name the application-layer join pattern explicitly.
+
+### Skill Instruction
+
+Read all database skills listed in the Databases column of the surface stack map (`.agent/instructions/tech-stack.md`) for advice on each store's transaction semantics and consistency guarantees before completing this step.
+
+### Output
+
+Write the completed cross-store consistency table to `architecture-draft.md` as part of the `## Data Strategy` section.

package/template/.claude/skills/database-schema-design/references/relational.md

@@ -0,0 +1,228 @@
+# Relational Database Schema Patterns
+
+Paradigm-specific patterns for the `database-schema-design` skill. Read `SKILL.md` first for universal methodology.
+
+Covers: **PostgreSQL**, **MySQL**, **SQLite**
+
+---
+
+## Normalization Examples
+
+### First Normal Form (1NF) — Eliminate Repeating Groups
+
+```sql
+-- NOT 1NF: repeating group in single column
+CREATE TABLE orders_bad (
+  id UUID PRIMARY KEY,
+  customer_name VARCHAR(255),
+  product_ids VARCHAR(255)  -- "1,2,3" - repeating group
+);
+
+-- 1NF: separate table for repeating data
+CREATE TABLE orders (
+  id UUID PRIMARY KEY,
+  customer_name VARCHAR(255),
+  created_at TIMESTAMP DEFAULT NOW()
+);
+
+CREATE TABLE order_items (
+  id UUID PRIMARY KEY,
+  order_id UUID NOT NULL,
+  product_id UUID NOT NULL,
+  quantity INTEGER NOT NULL,
+  FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE CASCADE
+);
+```
+
+### Second Normal Form (2NF) — Remove Partial Dependencies
+
+```sql
+-- 2NF: separate tables for partial deps
+CREATE TABLE enrollments (
+  id UUID PRIMARY KEY,
+  student_id UUID NOT NULL,
+  course_id UUID NOT NULL,
+  FOREIGN KEY (student_id) REFERENCES students(id),
+  FOREIGN KEY (course_id) REFERENCES courses(id),
+  UNIQUE(student_id, course_id)
+);
+
+CREATE TABLE courses (
+  id UUID PRIMARY KEY,
+  name VARCHAR(255),
+  professor_id UUID NOT NULL,
+  FOREIGN KEY (professor_id) REFERENCES professors(id)
+);
+```
+
+### Third Normal Form (3NF) — Remove Transitive Dependencies
+
+```sql
+-- 3NF: separate lookup tables
+CREATE TABLE states (
+  id UUID PRIMARY KEY,
+  code VARCHAR(2) UNIQUE,
+  name VARCHAR(100),
+  tax_rate DECIMAL(5,3)
+);
+
+CREATE TABLE orders (
+  id UUID PRIMARY KEY,
+  customer_city VARCHAR(100),
+  state_id UUID NOT NULL,
+  FOREIGN KEY (state_id) REFERENCES states(id)
+);
+```
+
+---
+
+## Relationship Patterns
+
+### One-to-Many
+
+```sql
+CREATE TABLE users (
+  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  email VARCHAR(255) UNIQUE NOT NULL,
+  name VARCHAR(255) NOT NULL,
+  created_at TIMESTAMP DEFAULT NOW()
+);
+
+CREATE TABLE orders (
+  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  user_id UUID NOT NULL,
+  order_date TIMESTAMP DEFAULT NOW(),
+  total DECIMAL(10,2),
+  FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
+);
+CREATE INDEX idx_orders_user_id ON orders(user_id);
+```
+
+### One-to-One
+
+```sql
+CREATE TABLE user_profiles (
+  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  user_id UUID UNIQUE NOT NULL,
+  bio TEXT,
+  avatar_url VARCHAR(500),
+  FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
+);
+```
+
+### Many-to-Many (Junction Table)
+
+```sql
+CREATE TABLE course_enrollments (
+  id UUID PRIMARY KEY,
+  student_id UUID NOT NULL,
+  course_id UUID NOT NULL,
+  enrolled_at TIMESTAMP DEFAULT NOW(),
+  FOREIGN KEY (student_id) REFERENCES students(id) ON DELETE CASCADE,
+  FOREIGN KEY (course_id) REFERENCES courses(id) ON DELETE CASCADE,
+  UNIQUE(student_id, course_id)
+);
+```
+
+---
+
+## Constraint Strategy
+
+```sql
+-- NOT NULL, UNIQUE, CHECK, DEFAULT
+CREATE TABLE products (
+  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  name VARCHAR(255) NOT NULL,
+  sku VARCHAR(100) NOT NULL UNIQUE,
+  price DECIMAL(10,2) NOT NULL CHECK (price > 0),
+  status VARCHAR(20) NOT NULL CHECK (status IN ('active', 'archived', 'draft'))
+);
+
+CREATE TABLE audit_logs (
+  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  table_name VARCHAR(100) NOT NULL,
+  operation VARCHAR(10) NOT NULL,
+  user_id UUID,
+  timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP
+);
+```
+
+---
+
+## Data Type Selection
+
+### PostgreSQL
+
+```sql
+CREATE TABLE users (
+  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+  email VARCHAR(255),
+  name TEXT,
+  age SMALLINT,
+  balance DECIMAL(15,2),       -- Financial data (precise)
+  is_active BOOLEAN DEFAULT true,
+  birth_date DATE,
+  last_login TIMESTAMP WITH TIME ZONE,
+  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+  metadata JSONB,
+  tags TEXT[] DEFAULT ARRAY[]::TEXT[]  -- PostgreSQL arrays
+);
+```
+
+### MySQL
+
+```sql
+CREATE TABLE users (
+  id CHAR(36) PRIMARY KEY,    -- UUID as CHAR
+  email VARCHAR(255),
+  name VARCHAR(255),
+  age TINYINT UNSIGNED,
+  balance DECIMAL(15,2),
+  is_active BOOLEAN DEFAULT true,
+  birth_date DATE,
+  last_login TIMESTAMP,
+  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+  metadata JSON,
+  KEY idx_email (email)
+);
+```
+
+---
+
+## Schema Evolution
+
+```sql
+-- Add column with default (backward compatible)
+ALTER TABLE users ADD COLUMN phone VARCHAR(20);
+
+-- Add constraint on new column
+ALTER TABLE orders ADD CONSTRAINT check_notes CHECK (LENGTH(notes) <= 500);
+
+-- Deprecate column safely
+ALTER TABLE users RENAME COLUMN old_field TO old_field_deprecated;
+```
+
+---
+
+## Performance: Partitioning
+
+```sql
+-- PostgreSQL: Partition by date range for time-series data
+CREATE TABLE events (
+  id UUID PRIMARY KEY,
+  user_id UUID NOT NULL,
+  event_type VARCHAR(100),
+  created_at TIMESTAMP NOT NULL
+) PARTITION BY RANGE (DATE_TRUNC('month', created_at));
+
+CREATE TABLE events_2024_01 PARTITION OF events
+FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');
+```
+
+---
+
+## Resources
+
+- [PostgreSQL Data Types](https://www.postgresql.org/docs/current/datatype.html)
+- [MySQL Data Types](https://dev.mysql.com/doc/refman/8.0/en/data-types.html)
+- [Database Normalization Guide](https://en.wikipedia.org/wiki/Database_normalization)