TezzDB Integration Guide

Data layer conventions for TezzNative platform services

TezzDB data model and operational flow

How the site currently stores app metadata, and the baseline conventions for extending the schema.

Current Table Contract

Table: tn_apps
Columns:
- id (INT, PK, AUTO_INCREMENT)
- name (VARCHAR 120, NOT NULL)
- status (VARCHAR 40, default "ready")
- updated_at (TIMESTAMP, auto-update)

Bootstrap Behavior

/api/apps ensures tn_apps exists.
If empty, it seeds:
- TezzNative Compiler
- TezzOS Builder
- TezzDB

This keeps first deploy functional without manual SQL.

DB Configuration

Create: web/tn_site/config/db.php

return [
  'site_name' => 'TezzNative',
  'site_url'  => 'https://tn.tezzcorp.com',
  'db_host'   => 'localhost',
  'db_name'   => 'tezznative',
  'db_user'   => '...',
  'db_pass'   => '...',
  'timezone'  => 'UTC',
];

Operational Queries

# health
GET /api/health

# version metadata
GET /api/version

# app registry
GET /api/apps

# smoke validation
tezz test --smoke

Extending TezzDB

Recommended next schema:
- tn_packages      (installed .gen package metadata)
- tn_services      (service state + autostart policy)
- tn_users         (auth and profile)
- tn_audit_log     (ops log for transparency)

Keep backward compatibility with /api/apps while introducing new endpoints.

TezzNative App Packaging Direction

.gen package plan:
1) metadata manifest
2) checksum/signature
3) install hooks
4) service registration in tn_services

Use TezzNative CLI as the package/install frontend and TezzDB as source-of-truth backend.