Prisma architecture: modules, API surface, dependency graph

At a Glance

---

What This System Does

Prisma is a general-purpose command-line tool built with TypeScript, Node.js. It operates as a command-line interface, enabling users to interact with the system through terminal commands. This architecture is optimized for automation, scripting, and integration into CI/CD pipelines.

Business Capabilities

The system is organized around 4 functional domains, each representing a distinct business capability:

Technical Foundation

Module Composition

The codebase follows a layered architecture with clear separation of concerns:

Codebase Health

Overall Health: 🟢 95/100

Key Insights

• ✅ Clean module boundaries — No circular dependencies detected, enabling safe refactoring and testing.
• ⚠️ Potential dead code — 36 files (17%) are not imported anywhere.

Key Data Flows

The system processes information through 5 identified flows:

• control Request Flow (critical) — Import chain starting from packages/1-framework/1-core/framework-components/src/exports/control — traces how this entry point depends on 1 downstream module
• runtime Request Flow (critical) — Import chain starting from packages/1-framework/1-core/framework-components/src/exports/runtime — traces how this entry point depends on 2 downstream modules
• authoring Request Flow (critical) — Import chain starting from packages/1-framework/1-core/framework-components/src/exports/authoring — traces how this entry point depends on 2 downstream modules
• codec Request Flow (critical) — Import chain starting from packages/1-framework/1-core/framework-components/src/exports/codec — traces how this entry point depends on 2 downstream modules
• components Request Flow (critical) — Import chain starting from packages/1-framework/1-core/framework-components/src/exports/components — traces how this entry point depends on 1 downstream module

Strategic Observations

• The codebase follows Core/kernel architecture — `packages/1-framework/1-core/framework-components`, `packages/2-sql/1-core/contract`, `packages/2-sql/1-core/schema-ir` (+6 more), Renderer pipeline — `packages/1-framework/1-core/ts-render`, Acyclic dependency graph — clean layering architectural patterns, providing a familiar structure for developers.
• Strong engineering practices are in place: automated testing and clean dependency boundaries support ongoing development.
• As a CLI tool, this system is automation-friendly and can integrate into existing workflows and pipelines.

---

This executive summary was generated from comprehensive repository analysis including dependency graphs, data flow detection, and architectural pattern recognition. Enable AI enhancement with `GITHUB_TOKEN` for strategic recommendations, risk assessments, and plain-language explanations tailored for non-technical stakeholders.

<!-- repolens:docs-badge -->  · Examples

The Big Picture

Prisma is a focused codebase with a clear purpose, containing 9 modules spread across 206 files.

---

Technology Stack

The system is built on a modern technology foundation:

Architecture Patterns

The codebase follows 3 identified architectural patterns:

• Core/kernel architecture — `packages/1-framework/1-core/framework-components`, `packages/2-sql/1-core/contract`, `packages/2-sql/1-core/schema-ir` (+6 more) — A structured approach to organizing code and managing complexity.
• Renderer pipeline — `packages/1-framework/1-core/ts-render` — A structured approach to organizing code and managing complexity.
• Acyclic dependency graph — clean layering — The system operates as a command-line interface, accepting user input through terminal commands and producing structured output.

Module Architecture

The system is organized into 3 architectural layers:

Layer Details

UI Components — 1 module

• packages/1-framework/1-core/framework-components — 89 files — User interface components

core — 7 modules

• packages/2-sql/1-core/contract — 64 files — Core application module
• packages/2-sql/1-core/schema-ir — 19 files — Data models and schemas
• packages/1-framework/1-core/errors — 9 files — Core application module
• packages/1-framework/1-core/ts-render — 8 files — Rendering and template logic
• +3 more modules

config — 1 module

• packages/1-framework/1-core/config — 6 files — Configuration management

Functional Domains

The following domains represent the largest functional areas by file count:

Dependency Graph

Codebase Health: 🟢 95/100

---

This system overview was generated from comprehensive repository analysis. Enable AI enhancement with `GITHUB_TOKEN` for narrative context, architectural rationale, technology trade-off analysis, and scalability recommendations.

<!-- repolens:docs-badge -->  · Examples

Overview

Prisma is organized into 4 functional domains, each representing a distinct area of business capability. This document maps the technical structure to business-oriented functional areas.

Quick Reference:

---

1. Data Layer

Business Capability

path packages/2-sql/1-core/contract matches sql

This is a major domain with 4 modules and 90 source files.

Key Modules

Business Impact

• Change Frequency Impact: High — Changes here affect 90 files
• Domain Complexity: Moderate
• Recommendation: Ensure comprehensive testing before modifying this domain

---

2. UI Components

Business Capability

path packages/1-framework/1-core/framework-components matches component

This is a major domain with 1 module and 89 source files.

Key Modules

Business Impact

• Change Frequency Impact: High — Changes here affect 89 files
• Domain Complexity: Simple
• Recommendation: Ensure comprehensive testing before modifying this domain

---

3. Core Engine

Business Capability

path packages/1-framework/1-core/errors matches core

This is a significant domain with 3 modules and 21 source files.

Key Modules

Business Impact

• Change Frequency Impact: Medium — Changes here affect 21 files
• Domain Complexity: Moderate

---

4. Configuration

Business Capability

path packages/1-framework/1-core/config matches config

This is a focused domain with 1 module and 6 source files.

Key Modules

Business Impact

• Change Frequency Impact: Low — Changes here affect 6 files
• Domain Complexity: Simple

---

Domain Health Summary

---

Domain mapping is based on directory naming conventions and code organization patterns. Enable AI enhancement with `GITHUB_TOKEN` for business-language descriptions, stakeholder impact analysis, strategic recommendations, and cross-domain relationship narratives.

<!-- repolens:docs-badge -->  · Examples

Architectural Philosophy

Prisma follows a Core/kernel architecture — `packages/1-framework/1-core/framework-components`, `packages/2-sql/1-core/contract`, `packages/2-sql/1-core/schema-ir` (+6 more) architecture with elements of Renderer pipeline — `packages/1-framework/1-core/ts-render`, Acyclic dependency graph — clean layering.

Pattern Analysis

Core/kernel architecture — `packages/1-framework/1-core/framework-components`, `packages/2-sql/1-core/contract`, `packages/2-sql/1-core/schema-ir` (+6 more)

A structured approach to organizing code and managing complexity.

Benefits: Structured organization, maintainability, clarity

Renderer pipeline — `packages/1-framework/1-core/ts-render`

A structured approach to organizing code and managing complexity.

Benefits: Structured organization, maintainability, clarity

Acyclic dependency graph — clean layering

The system operates as a command-line interface, accepting user input through terminal commands and producing structured output.

Benefits: Automation-friendly, scriptable, integrates with CI/CD pipelines

System Layers

The system is organized into 4 functional layers, each encapsulating a distinct area of responsibility:

Module Layers

Modules are classified into 3 architectural roles:

UI Components

Role: Renders user interface elements and manages component state

core

Role: Supporting application functionality

config

Role: Supporting application functionality

Technology Foundation

Scale & Complexity Analysis

Dependency Health

Architecture Health Score: 🟢 95/100

Architectural Strengths

• Clean module boundaries — No circular dependencies detected. This enables safe refactoring, isolated testing, and clear ownership boundaries.
• Testing infrastructure — Automated testing with Vitest supports confident evolution.

---

This architecture overview was generated from comprehensive dependency graph analysis and pattern detection. Enable AI enhancement with `GITHUB_TOKEN` for architectural narratives, design rationale explanations, scalability analysis, and refactoring recommendations.

<!-- repolens:docs-badge -->  · Examples

A complete inventory of all code modules in the repository, organized by location and size. Each module represents a distinct area of responsibility within the codebase.

Total modules: 9

---

Module Inventory

---

Module detection is based on the `module_roots` setting in your RepoLens configuration. Adjust this setting to change how modules are grouped.

<!-- repolens:docs-badge -->  · Examples

A complete listing of user-facing pages and backend API endpoints. This map shows every URL a user or client can interact with, along with the source file that handles each route.

---

Route Detection

This project is a CLI tool — it does not expose HTTP routes or serve web pages. This is expected behavior, not a detection failure.

CLI tools interact through terminal commands rather than URLs. See the System Overview or Developer Onboarding documents for command documentation.

<!-- repolens:docs-badge -->  · Examples

This page documents both the API endpoints the application exposes and the external services it integrates with. Use it as a reference for understanding the system's interfaces.

---

Internal API Endpoints

These are the backend services the application provides to handle incoming requests.

No API routes were detected in this scan. If your project uses a routing framework (Express, Fastify, NestJS, etc.), ensure the relevant directories are included in your scan.include patterns.

---

External API Integrations

Third-party services the application connects to, grouped by category.

No external API integrations were detected. This section populates automatically when RepoLens identifies SDK imports or API client usage in your codebase.

---

Documented Exports

Exported functions with JSDoc/TSDoc documentation. Documentation coverage: 82%

Function Documentation

packages/1-framework/1-core/config/src/default-contract-output-path.ts

`defaultContractOutputPath()`

Where contract emit writes the contract JSON for a config that names contractPath and sets no output: beside the contract file and named after it, or contract.json in the static prefix directory of a glob.

packages/1-framework/1-core/errors/src/control.ts

`errorConfigFileNotFound()`

Config file not found or missing.

`errorConfigEvaluationFailed()`

Config module failed to evaluate (syntax error, module threw during import).

`errorConfigVersionMarkerMissing()`

Config module evaluated, but its export does not carry the definePrismaConfig version marker (plain object export, or a config produced by a different defineConfig such as classic Prisma's).

`errorContractConfigMissing()`

Contract configuration missing from config.

`errorContractValidationFailed()`

Contract validation failed.

`errorFileNotFound()`

File not found.

`errorDatabaseConnectionRequired()`

Database connection is required but not provided.

`errorQueryRunnerFactoryRequired()`

Query runner factory is required but not provided in config.

`errorFamilyReadMarkerSqlRequired()`

Family verify.readMarker is required but not provided.

`errorJsonFormatNotSupported()`

JSON output format not supported.

`errorDriverRequired()`

Driver is required for DB-connected commands but not provided.

`errorContractMissingExtensions()`

Contract requires extension packs that are not provided by config descriptors.

`errorMigrationPlanningFailed()`

Migration planning failed due to conflicts.

`errorTargetMigrationNotSupported()`

Target does not support migrations (missing createPlanner/createRunner).

`errorMigrationCliConfigNotFound()`

Without --config, the migration-file CLI found no config whose migrations directory holds the migration.

`errorMigrationCliInvalidConfigArg()`

The migration-file CLI received --config without a path argument (either a bare trailing --config, or --config followed by another flag like --config --dry-run). Surfacing this as a structured error fails fast rather than silently consuming the next flag as the config path or falling back to default discovery against the wrong project.

`errorMigrationCliUnknownFlag()`

The migration-file CLI received a flag it does not recognise. Surfaced as a structured error so consumers can render their own "did you mean" suggestions from meta.knownFlags rather than parsing the message. Designed to wrap clipanion's UnknownSyntaxError at the parser boundary: pass the offending token as flag and the option declarations as knownFlags.

`errorInvalidOutputFormat()`

The main CLI received an unsupported --format value.

`errorOutputFormatMutex()`

The main CLI received mutually exclusive output format flags (--format pretty together with --json).

`errorConfigValidation()`

Config validation error (missing required fields).

`errorEnumCodecNotInPackStack()`

An enum declares a codecId that no component in the contract's pack stack provides, so its member values cannot be encoded. Thrown by both authoring paths (TS defineContract and PSL interpretation) when the codec lookup built from the contract's packs has no descriptor for the codecId.

`errorUnexpected()`

Generic unexpected error.

packages/1-framework/1-core/errors/src/execution.ts

`errorMarkerMissing()`

Contract marker not found in database.

`errorHashMismatch()`

Contract hash does not match database marker.

`errorTargetMismatch()`

Contract target does not match config target.

`errorMarkerRowCorrupt()`

Marker row exists but column values fail schema validation.

`errorMarkerReadFailed()`

Driver-level failure while reading the contract marker table.

`errorMarkerRequired()`

Database marker is required but not found. Used by commands that require a pre-existing marker as a precondition.

`errorSchemaVerificationFailed()`

Schema verification found mismatches between the database and the contract. The full verification result is preserved in meta.verificationResult.

Showing 30 of 261 documented exports.

---

Documentation Summary:

• Total exports: 317
• Documented: 261
• Undocumented: 56
• Coverage: 82%

---

HTTP method reference — GET: retrieve data, POST: create, PUT/PATCH: update, DELETE: remove.

<!-- repolens:docs-badge -->  · Examples

Understanding Data Movement

Data flows describe how information moves through Prisma — from external inputs through processing layers to storage or presentation. Understanding these flows is essential for debugging, performance optimization, and architectural decisions.

Flow Summary

5 data flows identified in the codebase:

---

1. control Request Flow 🔴 CRITICAL FLOW

Description

Import chain starting from packages/1-framework/1-core/framework-components/src/exports/control — traces how this entry point depends on 1 downstream module

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `control` (entry point, imports 14 modules)        │
│         ↓
│ `tagged-literal` (leaf — no further dependencies)  │
└─ END ───┘

Involved Modules

Insights

• ⚠️ Critical path — Failures here have significant business impact
• 📊 Consider adding monitoring and alerting
• 🧪 Ensure comprehensive test coverage

---

2. runtime Request Flow 🔴 CRITICAL FLOW

Description

Import chain starting from packages/1-framework/1-core/framework-components/src/exports/runtime — traces how this entry point depends on 2 downstream modules

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `runtime` (entry point, imports 13 modules)        │
│         ↓
│ `runtime-error` (shared infrastructure, used by... │
│         ↓
│ `runtime-error` (shared infrastructure, used by... │
└─ END ───┘

Involved Modules

Insights

• ⚠️ Critical path — Failures here have significant business impact
• 📊 Consider adding monitoring and alerting
• 🧪 Ensure comprehensive test coverage

---

3. authoring Request Flow 🔴 CRITICAL FLOW

Description

Import chain starting from packages/1-framework/1-core/framework-components/src/exports/authoring — traces how this entry point depends on 2 downstream modules

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `authoring` (entry point, imports 10 modules)      │
│         ↓
│ `framework-authoring` (shared infrastructure, u... │
│         ↓
│ `runtime-error` (shared infrastructure, used by... │
└─ END ───┘

Involved Modules

Insights

• ⚠️ Critical path — Failures here have significant business impact
• 📊 Consider adding monitoring and alerting
• 🧪 Ensure comprehensive test coverage

---

4. codec Request Flow 🔴 CRITICAL FLOW

Description

Import chain starting from packages/1-framework/1-core/framework-components/src/exports/codec — traces how this entry point depends on 2 downstream modules

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `codec` (entry point, imports 10 modules)          │
│         ↓
│ `data-type` (shared infrastructure, used by 6 f... │
│         ↓
│ `runtime-error` (shared infrastructure, used by... │
└─ END ───┘

Involved Modules

Insights

• ⚠️ Critical path — Failures here have significant business impact
• 📊 Consider adding monitoring and alerting
• 🧪 Ensure comprehensive test coverage

---

5. components Request Flow 🔴 CRITICAL FLOW

Description

Import chain starting from packages/1-framework/1-core/framework-components/src/exports/components — traces how this entry point depends on 1 downstream module

Characteristics

Processing Steps

Flow Diagram

┌─ START ─┐
│ `components` (entry point, imports 7 modules)      │
│         ↓
│ `runtime-error` (shared infrastructure, used by... │
└─ END ───┘

Involved Modules

Insights

• ⚠️ Critical path — Failures here have significant business impact
• 📊 Consider adding monitoring and alerting
• 🧪 Ensure comprehensive test coverage

---

Import Network

The system has 280 internal import edges connecting 206 source files.

Network Topology

---

Flow detection uses naming conventions, import patterns, and dependency graph analysis. Enable AI enhancement with `GITHUB_TOKEN` for end-to-end flow narratives, failure mode analysis, data transformation descriptions, and performance bottleneck identification.

<!-- repolens:docs-badge -->  · Examples

No changes detected.

<!-- repolens:docs-badge -->  · Examples

What is this? This visual diagram shows how different parts of your codebase connect to each other. Arrows indicate dependencies (which modules use which).

Showing: 9 modules and 0 relationships

Source: Real import analysis

---

Architecture Diagram

┌─────────────────────────────────────────────────────────────┐
│              🏗️  SYSTEM ARCHITECTURE MAP                    │
└─────────────────────────────────────────────────────────────┘

⚙️  CORE LOGIC
│
├── framework-components (89 files)
├── contract (64 files)
├── schema-ir (19 files)
├── errors (9 files)
├── ts-render (8 files)
├── config (6 files)
├── operations (4 files)
├── errors (4 files)
└── operations (3 files)
│

Legend:
  →  imports / depends on
  ╌→ tests

<!-- repolens:docs-badge -->  · Examples

Welcome to Prisma! 👋

This guide will help you get up to speed quickly. Prisma is a general-purpose tools project built with TypeScript, Node.js, containing 9 modules across 206 files.

What You'll Learn

1. ✅ Repository structure and organization
2. ✅ Technology stack and tools
3. ✅ Key modules to understand first
4. ✅ How data flows through the system
5. ✅ How to start contributing

---

Quick Reference Card

---

Repository Structure

Understanding the directory layout is your first step to navigating the codebase:

Where to Begin

Start by exploring the main src/ directory or look for entry point files like index.js, main.js, or app.js.

---

Technology Stack

---

Core Modules to Understand

These are the most important modules by size and centrality. Understanding them will unlock the rest of the codebase:

---

How Data Flows

Understanding these flows helps you see how the system processes information end-to-end:

Debugging tip: When investigating issues, trace the data flow from input to output to identify where problems occur.

---

Getting Started Checklist

Follow these steps to set up your development environment:

1. Clone and Install

git clone <repository-url>
cd prisma
npm install  # or yarn, pnpm

2. Explore the Structure

• Review the directory structure above
• Open the README.md for project-specific instructions
• Look for CONTRIBUTING.md for contribution guidelines

3. Understand Core Modules

Start with the high-priority modules listed above. Read the code and comments to understand:

• What problem each module solves
• How modules interact with each other
• What data structures are used

4. Run the Tests

npm test  # or: npx vitest run

Running tests helps you:

• Verify your setup is correct
• See expected behavior documented in test cases
• Understand module interfaces through test examples

5. Make Your First Change

Start small:

1. Find a small bug or typo to fix
2. Make the change in a feature branch
3. Run tests to ensure nothing breaks
4. Submit a pull request for review

---

Common Pitfalls

New contributors often run into these issues:

• Environment setup — Check for .env.example files and ensure you have all required environment variables.
• Branch naming — Follow the team's branch naming conventions (usually feature/, fix/, docs/).

---

Additional Resources

---

This onboarding guide was generated from comprehensive repository analysis. Enable AI enhancement with `GITHUB_TOKEN` for narrative walkthroughs, common pitfall documentation, debugging tips, architecture deep-dives, and personalized contribution recommendations.

Welcome to the team! Happy coding! 🚀

<!-- repolens:docs-badge -->  · Examples

No GraphQL schema was detected in this repository.

RepoLens scans for .graphql and .gql schema files, inline SDL via tagged template literals (e.g. gql\...\``), resolver patterns, and popular GraphQL libraries including Apollo, Yoga, Nexus, Pothos, Mercurius, type-graphql, Relay, and urql.

If your project uses GraphQL, ensure the relevant source directories are included in your scan.include configuration.

<!-- repolens:docs-badge -->  · Examples

117 file(s) with type declarations · 279 interface(s) · 253 type alias(es) · 30 class(es) · 238 relationship(s)

This document maps the type system of the project, showing how interfaces, classes, and type aliases relate to one another. Understanding these relationships helps navigate the codebase and identify coupling between modules.

Interfaces

279 interfaces define the data contracts used across the application:

Classes

30 classes provide concrete implementations:

Type Aliases

253 type aliases define computed or composite types:

Type Relationships

The following diagram shows inheritance, implementation, and reference relationships between types:

PslContractSourceProvider
  └── extends → ContractSourceProviderBase
TypeScriptContractSourceProvider
  └── extends → ContractSourceProviderBase
ContractSourceProvider
  ├── uses → PslContractSourceProvider
  └── uses → TypeScriptContractSourceProvider
MigrationPlanWithAuthoringSurface
  └── extends → MigrationPlan
FailedCast
  └── extends → FailedTypeChangeOf
FailedConversion
  └── extends → FailedTypeChangeOf
MigrationPlannerResult
  ├── uses → MigrationPlannerSuccessResult
  └── uses → MigrationPlannerFailureResult
FailedTypeChange
  ├── uses → FailedCast
  └── uses → FailedConversion
MigrationRunnerResult
  ├── uses → MigrationRunnerSuccessValue
  └── uses → MigrationRunnerFailure
SpaceSignature
  ├── uses → SpaceSigned
  └── uses → SpaceMarkerConflict
FieldCoordinate
  └── extends → ModelCoordinate
MigrationAccessChange
  └── extends → MigrationOperationSubject
MigrationDataLoss
  └── extends → MigrationOperationSubject
MigrationTemporaryValue
  └── extends → MigrationOperationSubject
FieldCoordinateJson
  └── extends → ModelCoordinateJson
ResolvedRenameStatement
  ├── uses → ResolvedModelRenameStatement
  └── uses → ResolvedFieldRenameStatement
ResolvedMigrationStatement
  ├── uses → ResolvedRenameStatement
  ├── uses → ResolvedFieldConvertStatement
  └── uses → ResolvedFieldBackfillStatement
MigrationSubject
  ├── uses → ModelCoordinate
  └── uses → FieldCoordinate
MigrationSubjectJson
  ├── uses → ModelCoordinateJson
  └── uses → FieldCoordinateJson
PslDefaultValue
  ├── uses → PslDefaultFunctionValue
  └── uses → PslDefaultLiteralValue
PslAttributeArgument
  ├── uses → PslAttributePositionalArgument
  └── uses → PslAttributeNamedArgument
PslFieldAttribute
  └── uses → PslAttribute
PslModelAttribute
  └── uses → PslAttribute
PslNamespaceEntry
  ├── uses → PslModel
  ├── uses → PslCompositeType
  └── uses → PslExtensionBlock
PslNamespaceNode
  └── implements → PslNamespace
VerifierOutcome
  └── uses → VerificationStatus
TransactionActivity
  └── extends → ActivityBase
ClientActivityResult
  └── uses → ClientActivityRegistry
Activity
  └── uses → TransactionActivity
ActivityEndedResult
  ├── uses → TransactionEnded
  └── uses → StatementEnded
RelationNamesOf
  └── uses → Rel
Scalars
  └── uses → Rel
Shape
  └── uses → ShapeOf
ShapeSpec
  ├── uses → PlusNames
  ├── uses → ScalarNamesOf
  ├── uses → RelationNamesOf
  ├── uses → RelatedModel
  └── uses → UnknownSpecKey
PlusNames
  ├── uses → RelationNamesOf
  └── uses → ScalarNamesOf
UnknownSpecKey
  └── uses → RelationNamesOf
ScalarNamesOf
  └── uses → Scalars
RelatedModel
  └── uses → UnwrapRelation
ShapeOf
  ├── uses → ShapeOfEach
  └── uses → PlusNamesAScalar
PlusNamesAScalar
  └── uses → ScalarNamesOf
ShapeOfEach
  ├── uses → Flatten
  ├── uses → KeptScalars
  ├── uses → IncludedRelations
  ├── uses → WrapLike
  ├── uses → ShapeOf
  ├── uses → RelatedModel
  └── uses → NestedSpec
KeptScalars
  └── uses → Scalars
IncludedRelations
  └── uses → RelationNamesOf
NamespacedEntities
  ├── uses → SingleNamespaceView
  └── uses → EntriesOf
IRNodeBase
  └── implements → IRNode
Namespace
  └── extends → IRNode
NamespaceBase
  ├── extends → IRNodeBase
  └── implements → Namespace
StorageType
  └── extends → IRNode
Storage
  └── extends → IRNode
AggregateOutputCodec
  ├── uses → SelfAggregateOutput
  └── uses → NamedAggregateOutput
AggregateDescriptorBase
  └── uses → AggregateResultNullability
NoInputAggregateDescriptor
  └── uses → AggregateDescriptorBase
AnyInputAggregateDescriptor
  └── uses → AggregateDescriptorBase
ValueInputAggregateDescriptor
  └── uses → AggregateDescriptorBase
AggregateDescriptor
  ├── uses → NoInputAggregateDescriptor
  ├── uses → AnyInputAggregateDescriptor
  └── uses → ValueInputAggregateDescriptor
CodecLookupWithDescriptors
  └── extends → CodecLookup
CodecRegistry
  └── extends → CodecLookupWithDescriptors
Cast
  └── uses → JsonValue
DataTypeReader
  ├── uses → JsonValue
  └── uses → DataTypeParams
DataTypeSpelling
  ├── uses → JsonValue
  └── uses → DataTypeParams
AuthoringFieldPresetOutput
  └── extends → AuthoringStorageTypeTemplate
AuthoringModelAttributeContext
  └── extends → AuthoringEntityContext
PslBlockDescriptorEntry
  └── extends → DescriptorEntry
AuthoringTemplateValue
  ├── uses → AuthoringArgRef
  └── uses → AuthoringSelectRef
AuthoringArgumentDescriptor
  ├── uses → AuthoringArgumentDescriptorCommon
  └── uses → ValueArgumentKind
AuthoringValueArgument
  └── uses → AuthoringArgumentDescriptor
AuthoringColumnDefaultTemplate
  ├── uses → AuthoringColumnDefaultTemplateLiteral
  └── uses → AuthoringColumnDefaultTemplateFunction
AuthoringTypeNamespace
  └── uses → AuthoringTypeConstructorDescriptor
AuthoringFieldNamespace
  └── uses → AuthoringFieldPresetDescriptor
AuthoringPslBlockDescriptorNamespace
  └── uses → AuthoringPslBlockDescriptor
AuthoringModelAttributeLoweringOutput
  ├── uses → AuthoringModelAttributeEntityOutput
  └── uses → AuthoringModelAttributeIndexOutput
CodecTypes
  └── uses → TypesImportSpec
PositionalArguments
  ├── uses → SignatureOptionalArgument
  └── uses → ArgumentOut
GeneratorHelper
  ├── uses → SignatureObject
  ├── uses → PositionalArguments
  └── uses → GeneratorFunctionCall
GeneratorHelpersOf
  ├── uses → Declared
  ├── uses → ContributionsOf
  └── uses → GeneratorHelper
AssembledControlMutationDefaults
  └── extends → ControlMutationDefaults
ControlMutationDefaultRegistry
  └── uses → ControlMutationDefaultEntry
PresetStorageTemplate
  ├── uses → ScalarTypeConstructorOutput
  └── uses → AuthoringStorageTypeTemplate
WrittenScalar
  └── uses → WrittenValue
ContractCode
  └── uses → ContractSubcode
OperationDescriptors
  └── uses → OperationDescriptor
JsonValue
  └── uses → JsonObject
JsonObject
  └── uses → JsonValue
IntegerStep
  └── extends → NumberClassification
HydratableStorageTable
  ├── uses → StorageTableInput
  ├── uses → Index
  └── uses → SerializedIndex
BackingObject
  ├── uses → ServingKey
  ├── uses → IndexCandidate
  ├── uses → UniqueConstraintInput
  └── uses → PrimaryKeyInput
NamedKey
  └── uses → Keyed
AuthoredIndexInput
  ├── uses → AuthoredIndexElements
  └── uses → AuthoredIndexMethod
IndexTypeRegistryImpl
  └── implements → IndexTypeRegistry
SerializedIndex
  └── uses → IndexElements
AggregateOperationTypes
  └── uses → AggregateResultType
AggregateTypesBase
  └── uses → AggregateOperationTypes
OperationOverloads
  ├── uses → ExactCodecIds
  ├── uses → OverloadResult
  └── uses → ExactOverloads
OverloadTable
  ├── uses → OperationsOf
  └── uses → OperationOverloads
CodecTraitsOfId
  └── uses → CodecTypes
SettledAggregateTypes
  ├── uses → OperationOverloads
  └── uses → CodecTypes
TypeMaps
  ├── uses → NamespacedFieldTypeMap
  ├── uses → NamespacedStorageColumnTypeMap
  └── uses → AggregateTypesBase
AggregateTypesOf
  └── uses → AggregateTypesBase
QueryOperationTypeEntry
  └── uses → QueryOperationSelfSpec
QueryOperationTypesBase
  └── uses → QueryOperationTypeEntry
ContractWithTypeMaps
  └── uses → TypeMapsPhantomKey
ExtractTypeMapsFromContract
  └── uses → TypeMapsPhantomKey
FieldOutputTypesOf
  └── uses → NamespacedFieldTypeMap
FieldInputTypesOf
  └── uses → NamespacedFieldTypeMap
StorageColumnTypesOf
  └── uses → NamespacedStorageColumnTypeMap
StorageColumnInputTypesOf
  └── uses → NamespacedStorageColumnTypeMap
ExtractCodecTypes
  ├── uses → CodecTypesOf
  └── uses → ExtractTypeMapsFromContract
ExtractQueryOperationTypes
  ├── uses → QueryOperationTypesOf
  └── uses → ExtractTypeMapsFromContract
ExtractFieldOutputTypes
  ├── uses → FieldOutputTypesOf
  └── uses → ExtractTypeMapsFromContract
ExtractFieldInputTypes
  ├── uses → FieldInputTypesOf
  └── uses → ExtractTypeMapsFromContract
ExtractStorageColumnTypes
  ├── uses → StorageColumnTypesOf
  └── uses → ExtractTypeMapsFromContract
ExtractStorageColumnInputTypes
  ├── uses → StorageColumnInputTypesOf
  └── uses → ExtractTypeMapsFromContract
ExtractAggregateTypes
  ├── uses → AggregateTypesOf
  └── uses → ExtractTypeMapsFromContract
ResolveCodecTypes
  ├── uses → ExtractCodecTypes
  └── uses → CodecTypesOf
NamespacedStorageWalk
  └── uses → Namespace
TablesOf
  ├── uses → Lookup
  └── uses → Namespace
ColumnTypesFromStorage
  ├── uses → Lookup
  ├── uses → Storage
  ├── uses → TablesOf
  ├── uses → ColumnTypeParams
  └── uses → CodecTypes
CheckConstraint
  └── extends → SqlNode
ForeignKeyReference
  └── extends → SqlNode
ForeignKey
  └── extends → SqlNode
PrimaryKey
  ├── extends → SqlNode
  ├── extends → SqlSchemaIRNode
  └── implements → DiffableNode
IndexInput
  ├── uses → IndexElements
  └── uses → SqlObjectNaming
Index
  └── extends → SqlNode
SqlNode
  └── extends → IRNodeBase
SqlAuthoringContributions
  └── extends → AuthoringContributions
SqlStorageTypeEntry
  ├── uses → StorageTypeInstance
  └── uses → StorageTypeInstanceInput
SqlNamespaceFactory
  ├── uses → SqlNamespaceInput
  └── uses → Namespace
SqlNamespaceEntries
  └── uses → StorageTable
SqlNamespaceBase
  ├── extends → NamespaceBase
  └── implements → SqlNamespace
StorageColumn
  └── extends → SqlNode
StorageTable
  └── extends → SqlNode
StorageTypeInstance
  └── extends → StorageType
AuthoredStorageTypeInstance
  └── uses → StorageTypeInstance
StorageTypeInstanceInput
  └── uses → StorageTypeInstance
StorageValueSet
  └── extends → SqlNode
UniqueConstraint
  └── extends → SqlNode
SqlOperationEntry
  └── uses → QueryOperationTypeEntry
SqlOperationDescriptor
  ├── uses → OperationDescriptor
  └── uses → SqlOperationEntry
SqlOperationDescriptors
  ├── uses → OperationDescriptors
  └── uses → SqlOperationEntry
SqlOperationRegistry
  └── uses → SqlOperationEntry
SqlCheckConstraintIR
  ├── extends → SqlSchemaIRNode
  └── implements → DiffableNode
SqlColumnDefaultIR
  ├── extends → SqlSchemaIRNode
  └── implements → DiffableNode
SqlColumnType
  └── uses → SqlColumnIR
SqlColumnIR
  ├── extends → SqlSchemaIRNode
  └── implements → DiffableNode
SqlDefaultValue
  └── uses → DataTypeValue
SqlForeignKeyIR
  ├── extends → SqlSchemaIRNode
  └── implements → DiffableNode
SqlIndexIRInput
  ├── uses → SqlIndexElements
  └── uses → SqlObjectNaming
SqlIndexIR
  ├── extends → SqlSchemaIRNode
  └── implements → DiffableNode
SqlSchemaIRNode
  └── extends → IRNodeBase
SqlSchemaIR
  ├── extends → SqlSchemaIRNode
  └── implements → DiffableNode
SqlTableIR
  ├── extends → SqlSchemaIRNode
  └── implements → DiffableNode
SqlUniqueIR
  ├── extends → SqlSchemaIRNode
  └── implements → DiffableNode

---

Generated by RepoLens static analysis. Type detection uses regex-based parsing and may not capture all advanced TypeScript patterns.

<!-- repolens:docs-badge -->  · Examples

206 files · 280 imports · 12 external packages · ✓ no circular dependencies · 36 orphan file(s)

This document maps every import relationship in the codebase, identifies the most-connected modules, and flags circular dependencies that may complicate refactoring or increase build times.

Overview

External Dependencies

The codebase imports 12 external packages. These are third-party modules (not the language standard library):

---

Generated by RepoLens import analysis. Dependency detection covers JavaScript and TypeScript (ES modules, dynamic import, CommonJS, re-exports; comments, strings, and type-only imports are skipped), Python (`import` / `from ... import`, including relative imports), and Go (`go.mod` module paths). Go `_test.go` files are not part of the graph.*

<!-- repolens:docs-badge -->  · Examples

No baseline found. Run repolens publish once to establish a baseline.

A baseline snapshot of the current architecture has been saved. On subsequent runs, this report will track structural changes across the following dimensions:

<!-- repolens:docs-badge -->  · Examples

9 security finding(s) · 1 medium severity · 8 low severity · across 8 file(s)

This report identifies code patterns that are commonly associated with security vulnerabilities. Each finding includes the relevant CWE classification and a recommended remediation.

Severity Overview

188 source files scanned · 8 files with findings

Prototype Pollution

Deep merge utilities may be vulnerable to prototype pollution if they don't check hasOwnProperty. Verify the implementation.

SQL Injection

Template literals with SQL and variable interpolation may be vulnerable. Use parameterized queries.

ReDoS

Dynamic regex construction from user input can cause ReDoS. Use static regex or input validation.

Affected Files

• packages/1-framework/1-core/errors/src/control.ts
• packages/1-framework/1-core/errors/src/execution.ts
• packages/1-framework/1-core/framework-components/src/annotations.ts
• packages/1-framework/1-core/framework-components/src/control/control-migration-types.ts
• packages/1-framework/1-core/framework-components/src/execution/runtime-error.ts
• packages/1-framework/1-core/framework-components/src/shared/runtime-error.ts
• packages/2-sql/1-core/contract/src/sql-data-type.ts
• packages/2-sql/1-core/contract/src/sql-raw.ts

---

Generated by RepoLens security pattern analysis. Detection is regex-based and may produce false positives. Findings should be triaged by a security-aware engineer.

<!-- repolens:docs-badge -->  · Examples

206 files analyzed · Average health: 90/100 · 164 A, 18 B, 20 C, 4 D, 0 F

This report synthesizes complexity, coupling, documentation, and security signals into a single health score per module. Lower scores indicate higher risk and maintenance burden.

Overview

Grade Distribution

Hotspots — Priority Refactoring Targets

These modules have the lowest health scores and should be prioritized for improvement:

Most Complex Functions

These functions have the highest cyclomatic complexity and are the most likely sources of bugs:

All Modules by Health Score

Showing 50 of 206 modules (sorted worst-first)

Scoring Methodology

The health score (0–100) is computed from four dimensions:

---

Generated by RepoLens code health analysis. Complexity covers JavaScript/TypeScript, Python, and Go. It is regex-based and may differ from AST-based tools. Scores are relative indicators, not absolute quality measures.

<!-- repolens:docs-badge -->  · Examples