Enfyra Developer Docs

This repository is the engineering documentation entrypoint for Enfyra contributors.

It is not product documentation, end-user documentation, or API marketing material. Its purpose is to help contributors understand how the Enfyra codebases are structured, which subsystems own which behaviors, where runtime data flows, and where to start debugging or implementing changes.

Scope

These docs cover two codebases:

• server Enfyra's programmable backend platform with metadata-driven REST/GraphQL, sandboxed execution, flow automation, websocket runtime, file/storage subsystems, and multi-database support.
• app Enfyra's Nuxt admin application, including schema-driven CRUD UI, Nitro bridge, OAuth/auth flows, realtime bridge, shared state, and contributor-facing feature maps.

Current Language Set

The current documentation set is:

• vi/ Vietnamese contributor documentation

The Vietnamese set is currently the primary and most complete version.

How To Read

Start from the language root, then follow the learning path in that language's README.

For the current Vietnamese set:

1. Open vi/README.md.
2. Follow the guided reading order for server or app.
3. Use the subsystem guides for architecture and contracts.
4. Use the feature maps and debug playbooks once you already know the relevant layer.

Document Types

The documentation is organized into a few recurring types:

• Overview Entry points that explain the learning order and subsystem boundaries.
• Architecture Boot order, request lifecycle, layout/routing, and runtime layering.
• Contracts Runtime object shapes, context contracts, state carriers, and integration boundaries.
• Maps Metadata maps, feature maps, and file-entry maps.
• Playbooks Symptom-based debugging guides.

Usage Rule

Read from entrypoint to subsystem.

Do not start by searching the codebase blindly unless you already know the subsystem boundary. Enfyra is intentionally layered, so fast progress depends on identifying the correct runtime layer first.

Maintenance Rule

When the code changes in a way that affects architecture, ownership boundaries, runtime contracts, file entrypoints, debug paths, or subsystem maps, the matching docs should be updated in the same change.