YAZA: Language, Compiler, Runtime, and Ecosystem Architecture

A Technical Architecture Book

Written and created by Yahya Zakariya
YAZA Programming Language (YAZA Lang)

Book information

Running header for the final paginated edition: YAZA Architecture · Yahya Zakariya

Running footer for the final paginated edition: YAZA Programming Language · Working manuscript · Edition 0.13

Book status: This English Markdown manuscript includes an original cover, author/title page, publication header/footer specification, linked contents, foreword, Mermaid architecture diagrams, implementation and target-architecture descriptions, comparison tables, glossary, source map, closing note, and implementation-versus-plan labels. It is maintained separately from the beginner-to-API tutorial. Word/PDF layout and final copy-editing are still pending. Do not use the future-design chapters as a product compatibility promise.

Copyright draft: © 2026 Yahya Zakariya. YAZA source code and third-party components retain their respective licenses. Confirm final copyright and licensing text before publication.

Author note: This manuscript credits Yahya Zakariya as the project creator and author. It does not add personal biography or origin details that have not been supplied for publication.

Foreword

YAZA is a programming-language project created by Yahya Zakariya. This book records how its compiler, runtime, command-line tools, API starter, and proposed ecosystem fit together. It is written both to explain the system to new readers and to keep the implementation honest: a working prototype, a partial feature, an accepted design, and a future idea must be described as different things.

YAZA's ambition is to bring language, tooling, APIs, data processing, and eventually web and mobile development into a coherent ecosystem. Ambition is a direction, not evidence of speed, security, completeness, or adoption. Those qualities must be demonstrated with implementation, tests, target support, and repeatable measurements. This manuscript therefore describes the capabilities that can be traced to the repository, explains the current gaps plainly, and gives future work a place without presenting it as already delivered.

The project is early. The compiler emits C and relies on a host C compiler for native output; the API's PostgreSQL Product operations now use YAZA code and passed a local PostgreSQL 17.6 CRUD/restart smoke, while its in-memory fallback, HTTP response writer, and startup/readiness path still cross into native runtime code; the HTTP server's request work is synchronous; and several security and portability requirements remain open. These boundaries matter because they tell contributors where the next engineering work belongs.

This foreword is the book's introductory statement from the creator. It avoids adding personal history or claims that are not recorded by the creator; the final public edition should receive the author's copy-editing approval.

Table of contents

Front matter

• Book information
• Foreword
• Executive summary

Chapters

1. How to read this book
2. YAZA at a glance
3. Project history and naming
4. Architecture principles
5. System map
   • Current native compilation and launch path
   • What “the YAZA engine” means today
   • Current API request path
   • Intended ecosystem dependency direction
   • Technology inventory and decision status
   • Architecture layers and contracts
6. The compiler and CLI
   • Compiler source and bootstrap
   • Build and run model
   • CLI responsibilities
   • Diagnostics and editor support
   • Why the current compiler emits C
7. The native runtime
   • What “runtime” means in YAZA today
   • Operating-system boundaries
   • HTTP server profile
   • Runtime composition and module boundary
8. Language model and current type system
9. How an API request runs
   • Project layout and declarations
   • Request lifecycle
   • Layered Product CRUD: what is and is not YAZA code
   • Generated API contracts and operations
10. Data access and PostgreSQL
    • The current API database path
    • Pure-YAZA PostgreSQL client
    • YAZA-authored API record adapter
    • Schema snapshots
    • Other databases
11. Memory and resource limits
12. Asynchronous I/O and scheduler
    • Implemented foundation
    • Current production boundary
    • Accepted target direction
    • Why “own and fastest” cannot be asserted yet
13. Security architecture and current limits
14. Build, install, and deployment
    • Current native CLI distribution
    • Platform status
    • Deployment boundary
15. First-party ecosystem modules
    • Modules with code today
    • Future module families
16. Current strengths and trade-offs
    • Evidence-backed strengths
    • Current costs and weaknesses
    • Potential ecosystem advantages, not results
    • Which workloads fit YAZA today?
17. Comparison with language runtimes and API frameworks
    • What the comparison does and does not say
    • Architectural trade-offs by approach
    • Comparison of API architecture patterns
    • Practical comparison by capability
18. Evidence, benchmarks, and release gates
    • Current evidence snapshot
    • What still needs independent proof
    • API-first exit rule
19. Roadmap and architectural risks
    • Priority order recorded by the project
    • Architectural risks
    • Decision and implementation ledger
    • Future target architecture, not current implementation
20. Glossary
21. Source map and references
22. Closing note

Executive summary

YAZA is an early compiled-language project whose source files use .yz and whose CLI is named yaza. Its current native compiler and CLI are authored in YAZA. The compiler emits C, then invokes the host C compiler to create a native executable. Selected native runtime code is compiled into that executable. YAZA is not currently a bytecode virtual machine, does not have a branded standalone VM, and does not use a Python environment to run its CLI.

The clearest working product path is the macOS Apple Silicon development CLI and an early HTTP API starter. The API has bounded HTTP/1 parsing, routes, typed request inputs, health and readiness endpoints, logs and metrics, and a Product Catalog example organized into controller, service, repository, model, interface, and route files. With DATABASE_URL, Product repository functions call the YAZA-authored PostgreSQL client for parameterized JSONB CRUD; local PostgreSQL 17.6 CRUD/restart and disposable PostgreSQL 18.6 lifecycle/CRUD smokes pass. Without a database URL, std/api/memory_records.yz calls a bounded native in-memory table adapter and returns results through normal handler serialization. Generated API binaries do not link libpq; remote TLS, broader database-version coverage, and automated database CI remain open.

This architecture has practical benefits for a small early project: generated C is inspectable, native compilation is available on the exercised host, and the same repository contains the language, compiler, runtime, templates, and evidence. It also has major costs: the C toolchain and C runtime are part of the native build boundary; the implementation is incomplete; only a narrow host profile is exercised; the HTTP server is synchronous; and language-level memory ownership, cross-platform targets, general database portability, web, and mobile are unfinished.

YAZA's design goals are broader than its present implementation. The project aims to build an integrated API-first ecosystem, followed by web, monolith, and mobile work. Performance, security, ease of use, and ecosystem advantages are goals to prove through finished implementation and repeatable measurements. They are not claims made by this book.

1. How to read this book

YAZA's current state changes as source code and tests change. Every capability in this book belongs to one of four categories:

When this book says “fast,” “safe,” “portable,” or “production-ready,” it must identify the measurement or acceptance evidence. It must not infer a comparative claim from implementation style alone. For current details, consult the runtime capability matrix, Appendix G status, Appendix H security status, and the API completion plan.

2. YAZA at a glance

YAZA is an early compiled programming-language and tooling project. Source files use .yz; the command is yaza. The compiler implementation and CLI are written in YAZA source, and the native bootstrap builds successive compiler stages. The current compiler translates the supported YAZA subset into C, then invokes a host C toolchain to produce a native executable.

The most complete application path is the macOS native CLI and API starter. That starter can run an HTTP/1 server, route requests, validate supported inputs, generate Postman/OpenAPI output, expose operational endpoints, and demonstrate layered controller/service/repository calls. With PostgreSQL configured, Product CRUD flows through YAZA repository functions and the YAZA client; the bounded process-local pool and lifecycle checks also use the pure-YAZA PostgreSQL client. Without a database, std/api/memory_records.yz calls a bounded native in-memory table adapter and returns results through the ordinary handler response path. Generated API binaries do not link libpq. Remote TLS verification, additional server versions, and automated database CI are still open.

The current product is not yet a complete cross-platform language platform. Linux and Windows installers, Linux API verification, independent runtime modules, browser/WASI targets, mobile compilation, the YAZA UI renderers, additional database engines, and a production async API remain unfinished.

2.1 Current engineering snapshot

3. Project history and naming

The project owner selected the name YAZA Programming Language / YAZA Lang, the CLI name yaza, and the .yz source extension. Earlier project drafts used other names; this architecture manuscript uses YAZA consistently. The repository history and current manifest are the appropriate sources for implementation history. No expanded meaning for the name or personal origin story is asserted here.

The documented project motivation comes from the creator's stated goal of building a programming language and toolchain that can eventually support APIs, web applications, data work, and mobile applications through one connected ecosystem. The owner set API completion as the first engineering priority, followed by web, monolith, and mobile work. This is the project's recorded direction, not a claim that the ecosystem is already complete or that every planned capability is unique to YAZA.

The working project root used in this manuscript is yaza-language. A future public distribution should publish a canonical repository URL, semantic versioning policy, license inventory, and supported-platform matrix. Until those are set and released, repository paths and package names are implementation details.

4. Architecture principles

These principles describe current design intent and the standards future changes should preserve:

1. Make the execution path inspectable. A reader should be able to trace source, compiler, generated C, runtime calls, and executable behavior.
2. Separate evidence from ambition. A proposal is useful design work, but it cannot be described as a working compiler or runtime feature.
3. Bound untrusted work. Parsers, requests, subprocess output, memory arenas, and connection counts need explicit limits before untrusted input can expand resource use.
4. Prefer portable contracts with explicit host adapters. OS interfaces, TLS providers, database protocols, and deployment targets require adapters and target-specific verification.
5. Keep the API as the first product gate. Web, monolith, and mobile work follows the API completion gates recorded by the project owner.
6. Use interoperability without hiding dependencies. Host C compilers, libpq, OS readiness APIs, and cryptographic providers are visible dependencies today; future packages must state which are build-time, runtime, or test-only dependencies.
7. Measure before claiming superiority. Benchmarks must compare equivalent builds, targets, workloads, and configurations.

5. System map

5.1 Current native compilation and launch path

flowchart LR
    A[.yz source and project manifest] --> B[YAZA CLI and compiler]
    B --> C[Lexing, parsing, supported type checks]
    C --> D[Generated C source]
    D --> E[Host C compiler and linker]
    E --> F[Native executable]
    F --> G[Included YAZA native runtime]
    G --> H[Operating system APIs]
    G --> I[Optional native libraries, such as libpq for API DB path]

The runtime source is incorporated into generated native programs as needed. It is not a separately installed YAZA virtual machine or bytecode interpreter. The compiler still depends on a host C compiler to build native output, and some target-specific functionality depends on platform libraries.

5.2 What “the YAZA engine” means today

The project currently has no separately branded execution engine or standalone VM. For clarity, this book uses these names:

The term “engine” should therefore mean the compiler plus native runtime as a system, unless a future specification gives a particular subsystem its own name. The project has not selected or shipped an LLVM backend, a YAZA bytecode VM, or direct machine-code generation.

5.3 Current API request path

flowchart TD
    A[Client request] --> B[Native HTTP readiness loop]
    B --> C[HTTP framing and JSON parsing]
    C --> D[Route and declared-input validation]
    D --> E[YAZA controller function]
    E --> F[YAZA service function]
    F --> G[YAZA repository forwarding function]
    G --> H{DATABASE_URL set?}
    H -->|yes| I[YAZA PostgreSQL repository]
    H -->|no| K[YAZA memory-record adapter]
    I --> J[Native HTTP response writer]
    K --> J
    L[Native libpq startup and readiness] -. separate connection .-> I

The Product sample's YAZA layers are part of the executable request path. PostgreSQL CRUD goes through the YAZA client; the no-database repository calls std/api/memory_records.yz, which operates on a bounded native table. Both paths return data or errors to the shared native HTTP response writer. Generated API binaries do not link libpq. The diagram makes these seams visible; it does not imply runtime-polymorphic interface dispatch or completed cross-platform/live-database coverage.

5.4 Intended ecosystem dependency direction

The ecosystem proposal groups future modules by responsibility. The intended direction is from language/runtime foundations to data and platform primitives, then to application frameworks and targets:

flowchart TB
    Core[Language core: types, errors, text, bytes]
    Runtime[Runtime: memory, I/O, process, crypto, async]
    Data[Data and document formats]
    DB[Database drivers and migrations]
    HTTP[HTTP and API framework]
    UI[YAZA UI and renderers]
    Pulse[YAZA Pulse realtime and streams]
    Atlas[YAZA Atlas maps]
    Targets[Native, WASI, browser, cloud, Android, iOS]
    Core --> Runtime
    Core --> Data
    Runtime --> Data
    Runtime --> DB
    Runtime --> HTTP
    Data --> HTTP
    DB --> HTTP
    HTTP --> UI
    HTTP --> Pulse
    Data --> Atlas
    UI --> Targets
    HTTP --> Targets
    Pulse --> Targets
    Atlas --> Targets

This is a planning map from the ecosystem module roadmap, not the current package graph. Several named modules are proposals or do not exist.

5.5 Technology inventory and decision status

This inventory gives readers a compact answer to “what is YAZA built with?” and distinguishes current implementation choices from future targets.

The table is a snapshot, not a permanent design mandate. Every replacement—such as a native compiler backend, independent runtime modules, or a new database provider—needs a design record, compatibility plan, and target-specific evidence before this chapter should describe it as current technology.

5.6 Architecture layers and contracts

The following map names the main layers a contributor encounters in the repository. It describes the present implementation and the boundary each layer currently owns; it is not a claim that every boundary is already a stable public interface.

The main dependency direction is application source → compiler → generated C → host toolchain → executable plus runtime → operating-system services. At an API boundary, a request enters the native HTTP runtime and reaches YAZA route and layer functions; configured Product persistence then enters the YAZA PostgreSQL client. This makes the integration seams visible and helps locate a bug without treating the whole stack as one opaque “engine.”

6. The compiler and CLI

6.1 Compiler source and bootstrap

The repository contains YAZA source for the lexer, expression parser, native compiler, and CLI. compiler/native_cli.yz implements the current source subset and emits C. The macOS bootstrap starts from a seed compiler, builds later compiler stages, and compares generated output from successive stages. This is a self-hosting/bootstrap milestone, not proof that no external toolchain is involved: a host C compiler is still used to create native binaries.

Current compiler responsibilities include tokenizing supported syntax, parsing expressions and indentation-based blocks, checking selected types and declarations, selecting project source files, generating C, including runtime support, and dispatching CLI commands. The implementation is intentionally narrower than the complete YAZA language vision. Generic traits, complete package resolution, ownership/borrow analysis, full source-location recovery, multiple independent compiler errors per pass, and multiple compiler backends are not established.

6.2 Build and run model

The native workflow is conceptually:

1. yaza reads command arguments. With yaza run and no source path, the current CLI looks in the working directory for src/main.yz, then main.yz. A project manifest can supply project metadata, but the current run entrypoint selection is based on those source paths.
2. The compiler expands supported local modules, tokenizes and parses the supported syntax, performs the implemented declaration/type and API checks, and emits generated C.
3. The CLI writes temporary generated C and invokes clang with the selected build/security flags and any platform libraries required by that source. API sources currently link libpq.
4. If compilation succeeds, yaza run starts the temporary native executable and forwards arguments after --. The current implementation removes its temporary executable and generated C after the child process returns.
5. For an API project, the native runtime reads its configured bind address and environment overrides, opens the listener, prints its startup endpoints, then enters its readiness loop. The exact target behavior is only verified on the stated macOS profile.

For the current project-root workflow, the expected shape is:

yaza check
yaza build src/main.yz -o api-server
yaza run

yaza run is a build-and-run command; it is not a standalone bytecode interpreter. yaza build <file.yz> -o <binary> creates a native executable through the C toolchain, while yaza run uses a temporary executable for the current source path. API builds also need the current libpq development dependency even when an individual run uses in-memory data, because the API compiler links that provider today.

The exact compiler flags and dependency set can vary by command and target. Check the installed CLI help and the native CLI installer guide rather than assuming a build from one host represents every operating system.

Logical std/... imports are searched in the current project, then under YAZA_STDLIB_DIR, /usr/local/share/yaza, and /opt/homebrew/share/yaza. Runtime-source lookup checks project/source-tree paths, YAZA_STDLIB_DIR/runtime, YAZA_RUNTIME_DIR, then the installed runtime locations. This lets a source-tree CLI find the matching runtime when invoked from another working directory by setting YAZA_STDLIB_DIR; installed packages provide both the runtime include and standard-library source tree.

6.3 CLI responsibilities

The current CLI includes project creation, source/project checks, native builds, run, test, formatting or auditing commands where available, API contract generation, database commands, and runtime diagnostics. The current command set should be checked with yaza help; future names such as package publishing or deployment must not be treated as implemented unless the CLI and its acceptance tests support them.

6.4 Diagnostics and editor support

The CLI can emit versioned JSON diagnostics for supported check failures. Current diagnostics remain partial: columns, imported-module mapping, richer stable error codes, and collecting multiple errors are incomplete. A VS Code extension supplies language registration, syntax highlighting, snippets, and file association; this is not yet a full language server with completion, semantic navigation, refactoring, and debugger support.

6.5 Why the current compiler emits C

The current compiler uses C as a bootstrap and native-code boundary. C offers a widely available host compiler and system-library interface on the exercised macOS profile, and it makes generated output inspectable while the YAZA compiler is still growing. This is an implementation decision for the current prototype, not a claim that C is the best permanent backend.

The trade-offs are significant. Native builds require a host C compiler; generated code and runtime support inherit C's portability and memory-safety risks; compiler diagnostics must map back through generated code; and target-specific system interfaces still need separate implementations and testing. A future LLVM, direct-codegen, or other backend would require a design decision, language conformance suite, source-location/debugging support, and target evidence. It must not be described as available until it exists and passes those gates.

7. The native runtime

7.1 What “runtime” means in YAZA today

The current YAZA runtime is native support code compiled into generated programs. It provides selected process, memory, filesystem, networking, HTTP, JSON, cryptographic, PostgreSQL, and diagnostic primitives. It is not a bytecode VM. The runtime source currently lives in a combined include file, runtime/yaza_runtime.c.inc; core, OS, HTTP, and PostgreSQL are not independently linkable runtime modules.

7.2 Operating-system boundaries

The C runtime has explicit host paths. macOS uses kqueue for HTTP socket readiness and CommonCrypto for selected cryptographic primitives; Linux source uses epoll and OpenSSL. The macOS readiness path is exercised. The Linux path is source-level implementation but has not passed a supported-host build/runtime acceptance matrix. Inbound HTTP TLS is not implemented. An experimental TLS client path exists but has interoperability and provider limitations, including deprecated Secure Transport on macOS and unverified Linux builds.

7.3 HTTP server profile

The current server is an HTTP/1 implementation with bounded parsing, a readiness-driven socket event loop, and a bounded API worker pool. It supports incremental request reads, selected HTTP/1.1 keep-alive and ordered pipelining, bounded chunked request bodies, deadlines for incomplete requests and response sends, and a finite connection count. Appendix H records the configurable 1–127 active-socket cap (default 64), five-second incomplete-request deadline, five-second keep-alive idle timeout, and 100-request keep-alive cap. Response bytes are queued under 16 MiB per-response and 64 MiB aggregate limits, flushed on writable readiness with at most 64 KiB per event-loop turn, and bounded by a five-second total deadline. The macOS loopback smoke exercises the supported behavior; Linux and broader conformance remain open.

Generated API handlers and PostgreSQL-backed readiness run on a bounded worker pool, with copied request state and event-loop-owned sockets/writes. Request deadlines return 504 and late jobs are discarded. http_request_cancelled() -> Boolean lets handler loops poll cancellation, but there are no compiler-inserted safepoints and native/blocking calls cannot be forcibly interrupted; a non-cooperative handler can occupy a worker; if it remains active after the configured shutdown grace, the process exits with failure rather than freeing state under that worker. HTTP/2, interoperable inbound TLS, an outbound HTTP client, source-level async tasks, multi-worker scheduling, and end-to-end backpressure across all stages remain unavailable.

7.4 Runtime composition and module boundary

At build time, the compiler includes native runtime support needed by the generated program. Runtime functions cover selected allocation, file and process operations, sockets, HTTP, JSON, cryptography, PostgreSQL support, logging, and diagnostics. The runtime is currently a combined native source include rather than a collection of separately versioned and independently linkable core, os, http, and pg libraries. Tree-shaking and a minimal per-feature runtime footprint are goals to measure after modular linking exists; they are not guaranteed by the current architecture.

8. Language model and current type system

The current compiler implements a selected statically checked subset. The book should explain it as it exists, not as a promise that every familiar language feature is present.

Type checking does not make untrusted network, file, database, or process input trustworthy. Runtime validation is still necessary at every external boundary.

9. How an API request runs

9.1 Project layout and declarations

The generated API template separates source into application entry point, route declarations, controllers, services, repositories, models, contracts, and interfaces. The compiler now checks service/repository metadata names, interface headers, duplicate method names, and exact one-to-one metadata signatures. This organization gives beginners a recognizable architecture, but it is not a full application framework with a general dependency-injection container, middleware pipeline, or typed runtime interface dispatch.

9.2 Request lifecycle

For an HTTP request, the runtime accepts or resumes a socket, parses and bounds framing, validates supported headers and body content type, matches a route, decodes declared inputs, validates supported types/constraints, invokes the generated action, and writes a response. Invalid request data is rejected before handler dispatch for the supported contract subset. Error envelopes and mapping are still incomplete across every failure class.

The current GET /api/products/{id} route makes the boundary visible:

1. The native listener receives bytes on a nonblocking connection. On the exercised macOS path, kqueue reports socket readiness; parsing and handler work then run on the single server thread.
2. The HTTP parser enforces request-size, header, body, and deadline limits. It rejects malformed framing and unsupported request forms before business logic.
3. The route table matches GET /api/products/{id} and extracts the declared path value. Supported authentication, request decoding, and validation checks run before handler dispatch.
4. The generated dispatch calls a YAZA controller function, which forwards to a YAZA service function, then to a YAZA repository function. These are real calls in the current API template, but the interfaces are not yet runtime-dispatched objects.
5. When DATABASE_URL is set, the YAZA repository checks out a connection from the bounded YAZA PostgreSQL pool, binds request values, runs a fixed CRUD query, releases or discards the handle, and returns Result[Text, ApiError]. Without a database URL, it calls std/api/memory_records.yz; the adapter mutates the bounded native table and returns a result. Startup/schema checks and readiness use the pure-YAZA PostgreSQL client.
6. The runtime writes the HTTP status, headers, and JSON body, keeps or closes the connection according to the supported HTTP/1 rules, and emits a structured response log with a sanitized path. Controller and database operations are synchronous within worker threads; the event loop alone queues and sends bounded nonblocking response output.

This trace explains why a well-organized .yz folder tree does not by itself mean the whole feature is implemented in YAZA. Controller/service/repository forwarding, PostgreSQL queries, and database lifecycle hooks are YAZA code. The in-memory table operations still cross a bounded native runtime adapter, as do HTTP parsing and response construction.

9.3 Layered Product CRUD: what is and is not YAZA code

The six Product routes use named YAZA controller, service, and repository functions. With DATABASE_URL, repository operations use std/pg/api_records.yz; otherwise they call std/api/memory_records.yz and its bounded native table adapter. Product create, replace, patch, and find strictly decode stored JSON into ProductRecord and return Result[ProductRecord, ApiError]; list returns Result[List[ProductRecord], ApiError] and serializes as a typed JSON array, and delete returns Result[ProductDeleteOutcome, ApiError] behind its bodyless 204 route. The adapter no longer emits HTTP responses; the ordinary handler path serializes results. Therefore:

• the route-to-controller-to-service-to-repository forwarding chain is executable and smoke-tested;
• Product interface files are not yet typed runtime dispatch contracts;
• PostgreSQL CRUD and lifecycle operations use YAZA code and a bounded process-local pool; the in-memory record table itself remains native runtime storage, while its repository adapter is YAZA. HTTP response construction remains native;
• local PostgreSQL 17.6 CRUD/restart and disposable PostgreSQL 18.6 lifecycle/CRUD evidence pass, but remote TLS and broader live-server acceptance/CI matrices remain open;
• the layered CRUD API completion gate remains open.

The API completion plan defines the release evidence needed to close this gap.

9.4 Generated API contracts and operations

Postman and OpenAPI generators handle a supported subset of route methods, path/query/header declarations, request examples, and schemas. Response models, every authentication policy, and every application error are not yet derived from one complete versioned contract. Route handlers may return Text, Option[Text], or Result[Text, E]; some(Text) and ok(Text) pass through JSON validation, none maps to a fixed 404 JSON envelope, and known ApiError cases map to fixed status/code envelopes. InvalidInput(field: Text) maps to a 422 response and includes the field only when it matches the bounded safe dotted-path or canonical array-indexed-path grammar (indexes 0 through 63); unsafe field text and unknown error payloads are omitted. An active handler can call http_set_status(Number) to choose from a checked status-code allowlist when its return value has no explicit status. The current Product delete handler uses it to return a bodyless 204 response. OpenAPI includes the known statuses, field-path schema, and the WWW-Authenticate/Retry-After headers. The API still lacks typed Result[Response[Model], ApiError], payload mapping beyond InvalidInput.field, and one complete contract for framework validation, authentication, and database failures. Health, readiness, metrics, structured logs, a shared bearer token, and exact-origin CORS exist in partial form. Loopback development may omit a token; non-loopback IPv4 startup fails closed without one. Role-based authorization and inbound TLS are absent.

10. Data access and PostgreSQL

10.1 The current API database path

With DATABASE_URL, generated Product repository functions, startup/schema checks, and /readyz use the YAZA PostgreSQL v3 client and bounded process-local pool; query values are bound separately. Generated API binaries no longer link libpq. Without DATABASE_URL, ProductRepository calls std/api/memory_records.yz, which operates on the bounded native in-memory table. The yaza db migrate, status, and snapshot commands also use the YAZA-authored client. Migration, CRUD/restart persistence, migration idempotence/status, catalog snapshot generation and fingerprint validation, and transaction/savepoint/recovery flows passed against local PostgreSQL 17.6; the database-configured API lifecycle and CRUD smoke passed against disposable PostgreSQL 18.6. Remote TLS, broader server CI, timeout/network failure recovery, and automated database CI remain open.

Before the lifecycle refactor, the API's native libpq path rejected connection modes without verified remote TLS. PostgreSQL documents prefer as a mode that can fall back to non-SSL and verify-full as the mode that verifies both the certificate chain and requested host name. (Connection security modes) The current YAZA PostgreSQL path requires sslmode=verify-full for remote hosts; explicit plaintext is restricted to numeric loopback hosts and checks the connected peer. Normal and ASan/UBSan HTTP smokes reject remote disable, prefer, allow, require, and verify-ca modes, plus unpinned localhost, before network access, and verify that credentials are not logged. Local live PostgreSQL API smoke verifies the current plain loopback path; a successful remote TLS handshake still needs live verification.

10.2 Pure-YAZA PostgreSQL client

YAZA-authored PostgreSQL modules cover connection-URI parsing, protocol foundations, transport, SCRAM-SHA-256, typed parameter framing, and selected query/transaction operations. std/pg/uri.yz parses both postgres:// and postgresql://, percent-decoded credentials/hosts/database/options, IPv4 and bracketed IPv6 forms, and the supported connection-option subset; it configures PG* values without logging credentials. Tests cover accepted and malformed URIs. The database CLI and generated Product API use this YAZA parser and transport. API migration and CRUD passed against local PostgreSQL 17.6; after the lifecycle-hook refactor, migration and full API HTTP smoke passed against disposable PostgreSQL 18.6. The API binary no longer links libpq. For local development, the YAZA transport permits plaintext only when PGSSLMODE=disable is explicit, the requested host is exactly 127.0.0.1 or ::1, and the runtime confirms through getpeername that the peer is loopback. Remote TLS behavior still needs successful live interoperability evidence on supported targets.

tests/pg_local_plaintext_fixture.c acts as a limited local PostgreSQL-protocol fixture. Bootstrap builds and runs the YAZA client against it, checking startup, SELECT 1, typed result decoding, and Terminate; normal and ASan/UBSan runs pass. This fixture validates protocol boundaries but is not itself a PostgreSQL server. Separately, the generated Product CRUD and migration CLI passed against PostgreSQL 17.6 on loopback with explicitly disabled TLS, and the current startup/schema/readiness hooks passed against disposable PostgreSQL 18.6.

10.3 YAZA-authored API record adapter

std/pg/api_records.yz provides YAZA functions for a generic JSONB record table: readiness probe, bounded list, get, insert, replace, patch, and delete. The SQL statements are fixed in the module; resource, ID, and object-size checks run before query execution; values use typed PostgreSQL bind parameters rather than SQL string interpolation. Insert reports a primary-key conflict, while get/replace/patch distinguish a missing row from a database error. The generated Product repository now calls these operations when DATABASE_URL is present and maps database failures to a fixed Unavailable error rather than exposing server text.

tests/pg_api_records.test.yz checks input bounds and result decoding. tests/pg_api_records_smoke.yz and tests/pg_api_records_fixture.c exercise the client against a strict loopback PostgreSQL-protocol fixture, including typed binds and injection-shaped payload data. A real local PostgreSQL 17.6 instance accepted the generated migration and full API CRUD smoke; a created record survived an API restart. A separate live smoke verified basic transaction commit/rollback, savepoint rollback/release, nested-BEGIN rejection, and recovery after a failed statement. Remote TLS, other server versions, broader transaction failure paths, and pool behavior remain unverified, so the database gate remains incomplete.

10.4 Schema snapshots

The portable snapshot is strict, versioned JSON (format version 2), with PostgreSQL major version, migration-set SHA-256 fingerprint, ordered tables/columns/constraints, and stable canonical ordering. A live PostgreSQL 17.6 smoke generated a snapshot from the catalog and validated its format and fingerprint offline. The format does not record every PostgreSQL object or establish that catalog queries work across all server versions; those compatibility checks remain open.

10.5 Other databases

No SQLite, MySQL/MariaDB, SQL Server, Oracle, Redis, or document database engine ships today. std/db/core.yz contains only the beginning of provider-neutral vocabulary and identifier checks. Provider-specific SQL semantics, wire protocols, transactions, type conversion, cancellation, pooling, migrations, and conformance suites must be implemented independently. A common interface cannot erase differences between relational, key-value, and document stores.

11. Memory and resource limits

The native allocator uses bounded arenas for the program and request scratch allocations. Current configured limits are 512 MiB for program allocations and 64 MiB for each serial HTTP request's scratch arena. In-memory CRUD records are explicitly promoted to longer-lived program memory so request cleanup does not erase persistent sample data. Scheduler tasks have a bounded task-local arena that survives a task yield and is reset when a task handle is reaped.

The standard library also has a fixed-storage process-local TTL cache. It holds up to 128 entries, with 255-byte keys and 4095-byte values, uses monotonic deadlines, protects table operations with a mutex, evicts the least-recently-used live entry when full, and wipes entry buffers on removal, replacement, expiry, clear, and shutdown. Cache contents are volatile and are not shared across processes. This adapter must not be used for secrets or authorization decisions.

These controls give the native runtime allocation accounting and predictable request cleanup in tested paths. They are not a YAZA language-level ownership model, garbage collector, process RSS cap, operating-system sandbox, or end-to-end proof against use-after-free. Allocations outside the wrapped runtime allocator are not included in its cap. Source-level Text is not yet a general pointer-plus-length value with uniform binary-safe semantics.

The 100,000-request RSS smoke recorded no sampled growth at ps's 1 KiB resolution in its latest run. That result applies to one workload and environment; it is not a universal memory guarantee or a competitor comparison. The TTL cache's fixed static storage is outside the request/program arena accounting and has its own entry and text-size caps.

12. Asynchronous I/O and scheduler

12.1 Implemented foundation

YAZA owns native readiness code and a deterministic scheduler core. The scheduler has bounded task slots, a FIFO ready queue, a deadline min-heap, generation-checked task handles, wakeups, child joins, cancellation/failure propagation, task-local memory, and deterministic tests. A C-core bridge can wake tasks from readiness events. Its microbenchmark exists, but sample variation exceeded the project's 5% comparison threshold; it cannot support a speed claim.

12.2 Current production boundary

The HTTP server now uses the scheduler and readiness bridge for one bounded request-reader task per connection; incomplete reads suspend until the socket becomes ready. The API smoke exercises this integration on macOS. Generated handlers and database-backed readiness run on the bounded worker pool while response writes suspend on writable events. There is no YAZA-visible async/await or M:N task scheduling in application code; PostgreSQL calls remain blocking within workers. The Linux epoll path has not been exercised on a Linux host.

12.3 Accepted target direction

RFC 0005 proposes structured task scopes, explicit cancellation and deadlines, many lightweight tasks over a bounded number of OS workers, readiness/completion-driven wakeups, a separate bounded pool for blocking operations, and multi-worker scheduling only after single-worker correctness and memory ownership. This target is not shipped. Its success criteria include fairness under saturation, no leaked tasks/sockets/database leases, race instrumentation for multi-worker behavior, and bounded queues and shutdown time.

12.4 Why “own and fastest” cannot be asserted yet

Owning the scheduler source is a useful design choice, but it does not itself guarantee better latency or throughput. Scheduling overhead, wakeup behavior, memory allocation, work distribution, blocking calls, connection limits, and application workload all matter. YAZA should publish repeatable comparisons only after language tasks, async I/O, HTTP integration, Linux verification, and benchmark controls are complete.

13. Security architecture and current limits

Appendix H tracks the security model and its gaps. The implementation contains meaningful hardening: strict HTTP framing; bounded parsers and arenas; request and process deadlines; safe percent-decoding; typed request validation; JSON escaping; conservative HTML/href escaping; parameterized API SQL; selected OS-backed cryptographic primitives; filesystem root handles; sanitizer builds; fuzz-test infrastructure; and an optional bounded per-client API rate limiter.

These features reduce selected risks. They do not make the current YAZA language memory-safe or certify the API for sensitive production data. Native C remains subject to C memory-safety defects. Current gaps include source-level ownership/unsafe boundaries, full cancellation, OS sandboxing, inbound HTTP TLS, broad authorization, secret lifetime/zeroization guarantees, dependency advisory scanning, complete data-flow analysis, live TLS/PostgreSQL verification, full Linux support, and independent security review.

As of 26 October 2026, the API refuses non-loopback IPv4 binds unless YAZA_API_TOKEN is set. It compares equal-length bearer values in constant time and rejects duplicate Authorization headers. When configured, a token bucket limits valid non-operational requests before authentication and computes the retry interval from its refill state. This is a safer bind default and a basic process-local limit; it does not add TLS, route-specific policy, distributed quotas, roles, or token lifecycle management.

yaza audit --security is a heuristic source/configuration review aid. It does not perform complete taint analysis, dependency vulnerability scanning, dynamic penetration testing, or a safety proof. Sanitizers and fuzzers cover particular executions and input spaces; passing them is evidence, not a universal guarantee.

The correct public statement is that YAZA has an early set of defensive runtime mechanisms and an unfinished security profile. Appendix H and the runtime matrix are normative for current status.

14. Build, install, and deployment

14.1 Current native CLI distribution

The macOS Apple Silicon bootstrap builds the native CLI from YAZA compiler sources using a seed YAZA executable and Apple's host C toolchain. The package script creates an unsigned .pkg; the package is still provisional and requires clean-machine installation review. The payload contains the CLI, combined native runtime source, std/ source modules, and project templates under /usr/local/share/yaza. The toolchain and installer do not require a Python virtual environment. A host C compiler is currently part of the build process.

14.2 Platform status

14.3 Deployment boundary

At present, the reliable workflow demonstrated by the repository is local native CLI/API development on macOS. Production deployment should wait for a versioned supported target, repeatable packaging, checksums/provenance, documented TLS termination, database verification, and the API release gates. A Cloudflare or Linux target must not be inferred from the native macOS executable.

15. First-party ecosystem modules

The ecosystem proposals aim for a coherent package family with shared project configuration, types, diagnostics, testing, security policy, and release evidence. “YAZA-owned” means source and maintenance are controlled by the project; it does not mean YAZA can avoid OS interfaces, external standards, hardware drivers, or interoperability adapters.

15.1 Modules with code today

Some early YAZA-authored modules exist:

• std/csv.yz: bounded CSV parsing/encoding slice; not a spreadsheet engine or streaming adapter.
• std/pdf.yz: deterministic one-page printable-ASCII PDF generation; not a general PDF reader/writer.
• std/html.yz: bounded HTML text/attribute escaping and conservative href validation; not a rich HTML sanitizer or full URL parser.
• std/pg/*.yz: selected PostgreSQL protocol/client foundations; not the generated CRUD driver's live end-to-end integration.
• std/fsroot.yz: bounded rooted file reads and atomic replacement; not a complete filesystem or sandbox.

The runtime capability matrix gives limits and linked tests for each module.

15.2 Future module families

The following designs are not all implemented:

The proposals should be read as system design proposals with technical risks, advantages, and exit criteria—not a product feature list.

16. Current strengths and trade-offs

16.1 Evidence-backed strengths

• The CLI/compiler source is written in YAZA and can be bootstrapped through successive compiler stages on the exercised macOS host.
• The native execution path is inspectable: generated C, host toolchain, and included runtime support are visible in the repository.
• The API starter has a recognisable layered layout, executable YAZA forwarding functions, HTTP smoke coverage, and Postman/OpenAPI generation for a supported subset.
• Selected parsers, file operations, HTTP operations, cryptographic primitives, tests, and child processes have explicit bounds and some sanitizer/fuzz coverage.
• The project tracks implementation separately from accepted RFCs and proposals, reducing the risk that a design is mistaken for a shipped feature.
• The language already has useful typed constructs such as shapes, variants, Option, Result, and selected error propagation.

These strengths describe verified slices. They do not establish enterprise readiness, broad compatibility, or superiority over mature platforms.

16.2 Current costs and weaknesses

• Native builds require a host C compiler and depend on a C code-generation/runtime boundary.
• The compiler, language, runtime, package workflow, and cross-platform support are incomplete; the current supported installation path is narrow.
• Runtime modules are combined rather than selectively linked as independent components.
• PostgreSQL Product CRUD now runs through YAZA repository code, but the native in-memory fallback and HTTP response/startup/readiness paths remain; interfaces are metadata, database portability and a complete contract/error model are unfinished.
• HTTP sockets are event-loop-owned; generated controller business handlers execute on bounded workers. The tested cooperative scheduler is not exposed to application code.
• The runtime's arenas do not provide source-level ownership safety; C undefined behavior remains possible.
• Linux/Windows, remote TLS/server security, broader PostgreSQL integration, web/mobile targets, and most ecosystem modules have open release gates.
• No fair cross-runtime HTTP benchmark has established throughput, tail-latency, memory, startup, or binary-size comparisons.

16.3 Potential ecosystem advantages, not results

One CLI, manifest, type vocabulary, diagnostics format, test runner, API contract model, and package policy could reduce glue code and mismatch between backend, web, data, and mobile components. A shared domain model could reduce duplicated validation and serialization. A selective native backend could help deployment size. These advantages depend on future implementations being coherent and reliable; none is a measured result today.

16.4 Which workloads fit YAZA today?

This is the practical comparison with an established ecosystem: YAZA is currently best treated as an inspectable compiler/runtime project and API prototype. The other workloads become reasonable recommendations only after their own release gates have passed.

17. Comparison with language runtimes and API frameworks

This comparison describes representative official toolchain models. It is not a performance ranking or a claim that one language is better for every job. Each language has multiple implementations and deployment modes; use the linked primary documentation for the scope of each row.

17.1 What the comparison does and does not say

The mature systems above have years of runtime, library, documentation, compatibility, and production experience. Their trade-offs differ: tracing GC can simplify ownership but costs runtime memory/accounting; compile-time ownership avoids a tracing collector but adds static rules; JIT can optimize from runtime profiles but requires a runtime phase; AOT can simplify startup/deployment but still needs sound runtime support and target-specific builds; event loops serve high-concurrency I/O only when callbacks/tasks do not block the loop.

YAZA should learn from these systems without copying their branding or assuming their trade-offs have one universal winner. An honest future comparison must use matched endpoints and data, identical keep-alive/TLS/database settings, warm-up rules, release builds, repeated runs, and disclose host/toolchain versions. Report throughput, p50/p95/p99 latency, RSS, startup time, and executable size. The YAZA HTTP benchmark remains not implemented.

17.2 Architectural trade-offs by approach

These comparisons are engineering lenses, not marketing claims. The right choice depends on latency objectives, memory budget, workload mix, operational constraints, libraries, and developer experience.

17.3 Comparison of API architecture patterns

This table compares common framework structures with the current YAZA API sample. The framework descriptions are based on their official documentation. The trade-offs are architectural interpretation, not measured productivity or performance results.

The comparison suggests a design choice for YAZA: keep the beginner-friendly layered template, while gradually making the route, middleware, interface, transaction, error, and repository contracts compiler-checked. That work should preserve explicit behavior and avoid hiding policy inside uninspectable code generation. This is a design recommendation, not an implemented feature.

17.4 Practical comparison by capability

This summary answers “what can a developer choose today?” It compares the current YAZA preview with established ecosystems, without treating feature count or source-language ownership as a speed measurement.

The practical present-day advantage of YAZA is project ownership of an inspectable compiler/runtime path and a unified API-first direction. The corresponding disadvantage is that this path is early and does not yet match the breadth, target support, safety guarantees, or operational maturity of established ecosystems. Future claims should be updated only when code and reproducible evidence change that comparison.

18. Evidence, benchmarks, and release gates

18.1 Current evidence snapshot

The repeatable checks are available in the live PostgreSQL smoke script and its transaction scenario. Run them only against a disposable database, as the script performs migrations and schema operations.

18.2 What still needs independent proof

• Linux build, API runtime, and installer on actual supported Linux hosts.
• Windows build and installer before Windows is advertised.
• Remote PostgreSQL TLS, cross-version compatibility, timeout/network failure recovery, and automated database-container coverage; local PostgreSQL 17.6 migration, snapshot, CRUD, restart persistence, and basic transaction/savepoint flows have passed manually.
• Interface-checked application layers with actual YAZA repository storage and typed error mapping.
• HTTP behavior under overload, long-running responses, cancellation, fairness, and hostile request sequences.
• Differential parser fuzzing against reference implementations and repeatable hosted fuzz results.
• Race/memory verification before multi-worker task scheduling.
• Cross-runtime performance benchmarks with pinned workload and machine/toolchain details.
• Supply-chain review, package provenance, reproducible release process, and security review.

18.3 API-first exit rule

The API stays the first completion target. Its release profile is complete only when the published API gates pass: executable typed layered CRUD; pure-YAZA PostgreSQL integration and live CI; unified versioned contracts/errors; security and operational middleware; additional provider engines behind conformance gates; and clean-install release evidence for supported targets. “100%” means complete against that versioned profile, not every imaginable framework feature.

19. Roadmap and architectural risks

19.1 Priority order recorded by the project

1. Finish the API as a verifiable product profile, completing typed repository contracts and removing avoidable native CRUD, response, startup, and readiness special boundaries.
2. Complete the generated PostgreSQL API path around the YAZA client, then verify remote TLS, failure recovery, supported server versions, and live CI.
3. Unify route, request, response, error, OpenAPI, and Postman contracts.
4. Complete security, authn/authz, middleware composition, resource bounds, cancellation, and deployment boundaries.
5. Add other database engines only with distinct provider contracts and conformance tests.
6. Establish Linux release and hosted fuzz/load evidence.
7. After API gates, resume web, monolith, and mobile targets.

The complete ordered gates are in the API completion plan.

19.2 Architectural risks

19.3 Decision and implementation ledger

This ledger separates the creator's product decisions from the code that currently fulfills them. The full rationale and acceptance criteria remain in the linked RFCs.

See RFC 0004 for API/database decisions and RFC 0008 for target sequencing.

19.4 Future target architecture, not current implementation

The accepted RFCs point toward a stable language core, explicit memory/unsafe model, portable module and package boundaries, structured concurrency, secure standard-library APIs, multiple compilation targets, and retained release evidence. These concepts should be turned into a versioned language/runtime specification before broad compatibility claims. The precise production compiler implementation must remain a documented decision: the current compiler emits C, while the blueprint has discussed a Rust implementation path. This manuscript does not silently resolve that choice.

20. Glossary

21. Source map and references

21.1 Repository sources

• Compiler source overview
• Runtime capability matrix
• Appendix G implementation status
• Appendix H security status
• API completion plan
• API template guide
• PostgreSQL schema snapshot format
• YAZA PostgreSQL connection URI parser
• PostgreSQL live verification smoke
• PostgreSQL transaction smoke program
• Native CLI installer guide
• RFC index
• YAZA ecosystem module roadmap
• YAZA UI proposal
• YAZA data/media/web module proposal
• YAZA Pulse proposal
• YAZA Atlas proposal
• Database driver proposal
• RFC 0004: Layered APIs and PostgreSQL
• RFC 0008: Cross-targets, WASI, edge, and mobile

21.2 Primary technical references

These official sources support the high-level runtime comparisons in Chapter 17. They describe the cited implementation or platform; they do not prove comparative performance.

• Go team, Go FAQ: runtime and compilation.
• Go team, A Guide to the Go Garbage Collector.
• Rust project, The Rust Programming Language: What Is Ownership?.
• Oracle, Java 26 Virtual Machine Technology Overview and Java 26 Virtual Machine Guide.
• Microsoft, .NET glossary: JIT, AOT, GC, and IL.
• Microsoft, .NET Native AOT deployment.
• Microsoft, .NET platform introduction.
• Node.js project, Node.js documentation overview.
• Node.js project, The Node.js Event Loop.
• Python Software Foundation, Python execution model and glossary.
• TypeScript project, The TypeScript Handbook.
• Dart project, Dart platform overview and dart compile.
• Flutter project, Architectural overview.
• Microsoft, ASP.NET Core middleware pipeline, routing, and MVC request mapping.
• Spring project, Spring Boot auto-configuration and Spring dependency injection.
• Go project, net/http package documentation.
• PostgreSQL project, libpq connection security modes and PQconninfoParse.

22. Closing note

YAZA's architecture is best understood as two things at once: a working early compiler/runtime with a narrow, testable native path, and a larger set of proposals for an integrated language ecosystem. Keeping those two views distinct makes the work easier to explain, safer to extend, and more credible to future users.

The next proof point is not a claim that YAZA is already faster, safer, or more complete than established runtimes. It is a finished API profile whose compiler-checked layers, PostgreSQL integration, security limits, supported targets, and repeatable tests can be inspected by another developer. Every ecosystem chapter after that should meet the same standard: a clear contract, an implementation that runs, a test matrix, documented trade-offs, and measured results where performance is claimed.

Manuscript changelog

• 2026-10-26: Expanded the architecture-layer and contract map, added a practical capability-by-capability comparison, made the creator's foreword explicit, and refreshed the Java comparison to the official Java 26 VM references; upgraded the working manuscript to edition 0.11.

• 2026-10-28: Documented the bounded process-local TTL cache, its fixed capacities, monotonic expiry, mutex protection, wiping policy, and explicit limitations; updated the implementation snapshot to edition 0.13.

• 2026-10-26: Documented the scheduler/readiness bridge integration with per-connection HTTP request-reader tasks, the fragmented-pipeline fairness check, and the remaining synchronous handler/database/write boundaries; updated the architecture risk table and implementation snapshot to edition 0.12.

• 2026-10-25: Updated standard-library and runtime-source search paths, including the YAZA_STDLIB_DIR and YAZA_RUNTIME_DIR overrides and the installed Homebrew prefix; recorded that the macOS package includes std/ sources; upgraded the manuscript to edition 0.6.

• 2026-10-25: Added the YAZA-authored parameterized PostgreSQL JSONB API-record adapter and its boundary; clarified that it is not yet wired into generated API routes; upgraded the manuscript to edition 0.7.

• 2026-10-25: Recorded the successful three-stage bootstrap after updating stale diagnostic assertions, 29/29 language tests, and normal plus sanitizer API-record fixture coverage; retained the distinction from live PostgreSQL integration.

• 2026-10-25: Connected generated Product repository operations to the YAZA PostgreSQL adapter for configured database requests, kept the in-memory fallback, and documented the remaining native libpq startup/readiness connection and live-server gaps.

• 2026-10-25: Added a generated API template build and in-memory HTTP smoke to the permanent bootstrap; the full updated bootstrap passes with 29/29 language tests and the PostgreSQL protocol fixtures.

• 2026-10-25: Expanded the architecture book with the exact current yaza run build/launch sequence and a step-by-step API request trace, including explicit YAZA-to-native runtime boundaries; upgraded the working manuscript to edition 0.5.

• 2026-10-25: Recorded the YAZA-written PostgreSQL connection-URI parser, its malformed-input and environment-configuration tests, and the remaining libpq boundary in the API profile.

• 2026-10-25: Added an original book cover, publication header/footer metadata, an architecture decision ledger, and an API-framework comparison; clarified draft versus final Word/PDF status.

• 2026-10-25: Documented the tested loopback-only PostgreSQL plaintext mode, the actual-peer address check, and the boundary between fixture evidence and live PostgreSQL compatibility.

• 2026-10-25: Recorded the API libpq policy requiring verified remote TLS and explicit loopback-only development plaintext, with normal and ASan/UBSan smoke evidence.

• 2026-10-25: Added an explicit author/title page, organized the table of contents into front matter and chapters, recorded the creator-stated project motivation, and added a technology inventory separating current implementation from future targets.

• 2026-10-25: Recorded the verified Result[Text, E] API outcome path: Ok(Text) returns the validated JSON body, and Err(E) maps to a fixed generic 500 envelope without exposing the error payload. Normal and ASan/UBSan HTTP smoke checks pass.

• 2026-10-25: Added the template's typed ApiError unit-case mapping and shared OpenAPI status schemas, including the 401 challenge and 429/503 retry headers. Normal HTTP, ASan/UBSan HTTP, and OpenAPI generation smoke checks pass.

• 2026-10-25: Recorded the live PostgreSQL 17.6 migration and end-to-end API CRUD/restart-persistence smoke; added explicit typed Product request-body metadata; implemented handler-set response statuses and bodyless 204 responses; updated the API, G, H, and runtime capability evidence; upgraded the manuscript to edition 0.8.

• 2026-10-25: Added a bounded InvalidInput(field: Text) response mapping. Valid dotted identifier paths and canonical array-indexed paths (indexes 0 through 63) are included in 422 responses; invalid field text is omitted. OpenAPI and HTTP smokes verify the schema, safe path, and rejection behavior under normal and ASan/UBSan builds.

• 2026-10-25: Recorded the typed Option[Text] API handler response path and its safe 404 mapping, including the template smoke evidence.

• 2026-10-25: Updated the code-backed snapshot after API layer metadata conformance work; clarified what “YAZA engine” means today; expanded the workload fit and trade-off analysis; added primary-source comparisons for Python, TypeScript/JavaScript, and Dart/Flutter; and added an executive summary and author note.

• 2026-10-25: Updated the database chapters and decision ledger with live PostgreSQL 17.6 catalog snapshot, fingerprint validation, transaction, savepoint, and failed-statement recovery evidence; corrected older statements that still described these checks as unverified; upgraded the manuscript to edition 0.9.

• 2026-10-26: Added the implemented opt-in IPv4 token-bucket limiter, its bounded fail-closed table behavior, smoke/sanitizer evidence, and remaining distributed/route-policy limits; updated the implementation snapshot to 26 October 2026 and edition 0.10.

• 2026-10-24: Created the architecture book structure and first complete technical draft from current repository evidence. Added current compiler/runtime flow, API and PostgreSQL boundaries, async/scheduler status, security and target limits, ecosystem status, trade-offs, official runtime references, glossary, and publication checklist notes.

← Kembali ke semua dokumentasiVersi dan status rilis →