Skip to content

Core Internals

github-actions[bot] edited this page Aug 19, 2026 · 1 revision

Praxis Core Internals

Core Internals documents the code that interprets intent and writes repositories. It does not describe the generated application's runtime except where that boundary is necessary to explain composition.

flowchart TD
    CLI[cli/command] --> Workflow[workflow/runCreate]
    Workflow --> Config[config schema and prompts]
    Config --> Resolver[config/resolver]
    Resolver --> Manifests[templates/*/manifest.json]
    Manifests --> Composer[composer/compose]
    Composer --> Output[generated repository]
    Tests[contract and matrix tests] --> CLI
    Tests --> Resolver
    Tests --> Composer
Loading

Reading order

  1. Architecture for repository and trust boundaries.
  2. Repository-Map for ownership.
  3. Code-Architecture for typed abstractions and dependency direction.
  4. Generation-Pipeline for execution order and failure behavior.
  5. Manifest-System for overlays, selectors, packages, environment, and patches.
  6. UI-Templates for the separately generated visual-template artifacts.
  7. Testing for evidence requirements.

Core invariants

  • Configuration is validated before module resolution.
  • Module order is deterministic.
  • Manifest paths cannot escape approved template or staging roots.
  • Composition writes to a sibling staging directory and never leaves a partial destination.
  • Package/script conflicts fail rather than silently selecting a winner.
  • Generated outputs do not import Praxis at runtime.
  • Requested and resolved Pro capabilities remain separately recorded.

Authoritative entry points

For generated runtime behavior, continue to Template-Architecture.

Clone this wiki locally