KernDX

📚 Browse the documentation site — the same Fast Starts, Strategic Guides, and Apex reference under docs/, rendered and searchable.

Ship Apex and LWC features in a fraction of the time.

Most Salesforce open-source gives you a library. KernDX gives you the library — plus the onboarding, CI, and guardrails around it.

One managed package, but not all-or-nothing: switch on the parts that fit your situation, and the rest is there the day you need it.

• One core, one convention — triggers, queries, DML, APIs, async, validation, logging, data masking, and LWC, all on one consistent path with shared TRG_* / SEL_* / DML_* / LOG_* naming. Learn one layer and you know the rest.
• Onboarding in the box — docs, Fast Starts, AGENTS.md, and canonical conventions, so a new hire (or an AI assistant like Claude Code or Cursor) writes convention-compliant code on day one.
• CI in the box — PMD rulesets, an ESLint plugin, secret scanning, and coverage gates that drop into your pipeline.
• Guardrails built in — reads and writes run FLS-safe by default, 100% Apex / 95% LWC coverage is enforced at every release, and bypasses are audit-logged with the reason the caller gave, so a security review can start from a query.
• Yours to keep — source-available under BSL 1.1, no lock-in: run the managed package, repackage under your own namespace, or run the source yourself.

Came here looking for…

If you want	KernDX gives you	Try it in 30 min
Trigger framework	metadata-driven + audit-logged bypass + 4-level kill switch + recursion control	Fast Start - Trigger Actions
SOQL query builder	FLS-enforced by default + audited bypass + fluent API + subclassable	Fast Start - Selectors
DML wrapper	USER_MODE default + transactional batching + async DML + dependency graph	Fast Start - DML
Outbound HTTP	retry / circuit-breaker / idempotency body-hash / dead-letter queue	Fast Start - Outbound APIs
Inbound REST	two-class routing pattern + DTO marshalling + body-hash 409 on replay	Fast Start - Inbound APIs
Logging	platform-event transport + correlation IDs threaded across triggers/async/HTTP	Fast Start - Logging
Async orchestration	chained Queueables + shared state + finalizer recovery + Chain Monitor LWC	Fast Start - Async Processing
Test data factory	builder pattern + parent-child wiring + DML-free selector mocks	Fast Start - Test Data
Feature flags	metadata + per-user/profile + Apex/Flow/LWC + pluggable strategies	Fast Start - Feature Flags
Custom validations	metadata-driven + shadow mode + 3-level bypass — zero Apex	Fast Start - Custom Validations
Resilient callouts	retry + exponential backoff + circuit breaker on any callout, no boilerplate	Fast Start - Resilience
Secure data access	USER_MODE CRUD/FLS enforced on every read and write by default	Fast Start - Security
Data masking	write-time field redaction on a configurable field set + a Data Masking Advisor to scan, deploy config, and inventory regulated fields	Fast Start - Data Masking
LWC components	base class with toasts, Apex calls, navigation, and logging wired in	Fast Start - LWC

→ Comparing against alternatives? Choosing a Framework covers head-to-head trade-offs vs taf, fflib, rflib, nebula-logger, apex-libra, the Apex Fluently libraries, and fflib-mocks.

KernDX is a complete Salesforce framework and library suite — one managed package that replaces a dozen separate libraries: SOQL query builder, DML wrapper, trigger framework, async orchestration, REST APIs (inbound + outbound), feature flags, validation, logging, data masking, test data factory, LWC components, and the CI tooling to keep it all clean. You focus on business logic, not infrastructure.

This repository is the public release repo for KernDX. main is fast-forward-only and tracks subscriber package version 1.1.0-11 at this snapshot.

Why "KernDX"?

Kern, for kernel — a dependable core your Apex and LWC run through: every read, write, and async hop on one consistent, access-controlled path. DX, for developer experience — the docs, conventions, AI-agent onboarding, and CI in the same box. It's the core of your codebase, not a replacement for the Salesforce platform — the platform is still the platform.

And like a kernel, it's not all-or-nothing. Switch on the parts that fit your situation — just the query layer today, the trigger framework when you need it, logging or data masking when you're ready — knowing the rest is there the day you do. You adopt at your own pace; nothing forces you to take the whole thing to get value from one piece.

Architecture at a glance

Every read goes through a selector (FLS-enforced); every write goes through DML_Builder (USER_MODE by default); every cross-transaction chain goes through AsyncChain (correlation IDs threaded); every framework call emits to LOG_Builder. One mental model across the stack.

Why so opinionated?

100% Apex coverage. 95% LWC coverage. Default-on FLS + CRUD on every read and write. PMD-clean code as a PR gate. Naming prefixes enforced by scanner. We know — it sounds like a lot.

It exists because frameworks decay. Constraints that feel restrictive at month one are the only thing keeping framework guarantees true at month thirty-six, after a dozen contributors, three "we'll come back and fix this" detours, and one Salesforce release with a breaking change. Default-on means a tired engineer at 11pm can't accidentally ship a bypass; PR-gates mean a new hire can't accidentally normalize one.

The constraints are deliberate, documented, and ship as enforceable gates — not gentle suggestions. If you adopt the framework, you get the discipline as a side effect.

Install paths

	Path 1 — Managed package	Path 2 — Repackage under your namespace	Path 3 — CI tooling only
Who it's for	Salesforce admins / developers adding KernDX to an existing org.	Teams that want to embed KernDX inside their own managed package.	Teams that want the KernDX CI pipeline without the framework itself.
What gets installed	The kern managed package at 1.1.0-11. All code lives under the kern namespace.	Your own managed package built from KernDX source under your namespace.	ESLint plugin + 2 PMD rulesets + 10 GitHub Actions workflow templates. Zero framework code.
Install command	sf package install --package 04tfj000000KesXAAS --target-org <alias> (04t in RELEASE-PROVENANCE.json).	node bin/swap-namespace.js <your-namespace> then build your own package.	Download KernDX-1.1.0-11-pipeline.zip → unzip + (cd .kerndx-pipeline/pipeline && npm ci --omit=dev) + ./.kerndx-pipeline/bin/kerndx init.
When to choose	You want the framework as a managed dependency you can swap in days, not weeks.	You're building a managed package and want KernDX inside it as your code.	You don't want the framework but you want the conventions enforced in your CI.
Full guide	Installation — Path 1	Installation — Path 2	Installation — Path 3 · preview 9 workflow examples

Evaluate in a scratch org (no managed-package dependency)

One click deploys force-app/ source into a scratch or sandbox org you nominate, so you can poke at the framework before deciding which install path is right for you. Deploying the source directly is a genuine option — the same unmanaged delivery you'd use to own the code outright — but it ships without the managed-package upgrade lifecycle, so it isn't the recommended way to run KernDX day-to-day: you'd reconcile changes by hand on each update instead of installing a new package version. It is the fastest way to read real code in a real org, and your assurance that you can always run the framework yourself.

Quick start

> Developer-focused. This Quick Start is for contributors cloning the source tree to run tests or contribute. Subscribers installing the framework: see Installation — Path 1 — you do not need to clone the repo.

git clone https://github.com/JVB-Consulting/kerndx.git
cd kerndx

# Node 22 required — .nvmrc pins it.
nvm install 22
nvm use

npm ci

# Required for release tests against a subscriber org.
export SF_SUBSCRIBER_ORG_ALIAS=<your-subscriber-scratch-org-alias>

# Run the LWC Jest suite (scoped to force-app/).
npm run test:unit

# Run the Apex tests against your subscriber org.
npm run release:phase2

Other test entry points

Script	Scope
npm run test:unit	LWC component tests under force-app/ (default Jest suite).
npm run test:scanner	KernDX ESLint plugin rule tests (scanner/eslint-plugin-kerndx/__tests__/).
npm run test:release	Release-testing runner unit tests (requires SF_SUBSCRIBER_ORG_ALIAS).
npm run test:pipeline	Pipeline native-test suite (cd pipeline && npm ci --omit=dev && npm test). Clones from this repo automatically skip the test files that depend on internal-only subscriber-naming fixtures; the wrapper logs the skipped files and runs the remainder.
npm run test:e2e	Playwright smoke. Run npx playwright install --with-deps once first. Requires SF_SUBSCRIBER_ORG_ALIAS.

Environment variables by script

Variable	Required for	Notes
SF_SUBSCRIBER_ORG_ALIAS	release:phase2, test:release, test:e2e	sf-cli alias for the subscriber scratch/sandbox org the release tests target. The runner fails fast with a clear message if unset.
KERN_DEV_ORG	build:package, setup:scratch-org, scan:flow-refs, evaluate:coverage, docs:build	sf-cli alias for your dev scratch org. Only needed if you run the dev-tooling scripts under scripts/ — not required for any of the test entry points above.
ICAPEXDOC_HOME	docs:build (optional)	Absolute path to your local IcApexDoc install (see release page). Only needed to regenerate the Apex reference docs locally.

Where to go next

• Looking for docs that match a specific installed version? This README and the docs under docs/ always track the latest release (currently 1.1.0-11). Every release is preserved as a git tag vX.Y.Z-N — browse the Tags page (or Releases for richer per-release notes) and check out the matching tag (e.g. git checkout v1.1.0-11). Every file in this repository — README, install commands, API reference, Strategic Guides — is frozen at the state of that release.
• Release Notes — Kern 1.1 — what's new since v1.0, grouped by capability, with upgrade notes. Read this first if you are evaluating an upgrade.
• Release Notes — Kern 1.0 — the comprehensive feature reference for the framework 1.1 builds on, grouped by capability. (The top-level CHANGELOG.md is a sequential per-build log for diagnostic use — the release notes are the subscriber-facing summary.)
• Documentation hub — learning paths, Fast Starts, Strategic Guides, Apex reference.
• Installation guide — install + namespace-swap workflow.
• Fast Starts — 16 task-oriented guides (Selectors, DML, Test Data, Security, Data Masking, Logging, Feature Flags, Outbound APIs, Resilience, Inbound APIs, Trigger Actions, Custom Validations, Async Processing, LWC, E2E Testing, Code Scanning).
• Module guides — long-form reference per framework area (LWC, Security, Data Masking, Triggers, Web Services, Resilience, Async, Validation, DML, Selectors, Logging, Feature Flags, Utilities, Test Data, DTOs, Objects & Metadata, Code Scanning, E2E Testing).
• Apex reference — auto-generated ApexDoc + LWC reference.
• Strategic Guides — adoption decisions, architecture rationale, operations, personas, glossary, metrics.
• Code Conventions — canonical code-style + framework rules.
• Workflow examples — pre-rendered previews of 9 of the 10 GitHub Actions workflow templates the kerndx-pipeline distribution scaffolds.

Contributing

v1.0: bug reports and feature requests are welcome via GitHub Issues. External PRs are not currently accepted at this stage of the project — each release overwrites the branch state, so a PR merged here would be replaced on the next release. The issue-first workflow is the supported path. See CONTRIBUTING.md for the full v1.0 contribution model + rationale.

Security vulnerabilities: do not open a public issue. See the security policy for the responsible-disclosure process.

Need a hand?

Paid enterprise support is available for teams that want a faster path on top of the source-available framework:

• Adoption consulting — namespace-swap planning, repackaging strategy, CI integration.
• Customisation — bespoke selectors, validation rules, async chains, or LWC components against the framework conventions.
• Audit + review — code-conventions audit, coverage-theatre detection, performance baseline review.

Contact: jason@jvb-consulting.io. The framework itself is and remains BSL 1.1 source-available with a four-year clock to Apache 2.0; the support engagement is the optional fast path, not a gating dependency.

Licensing

• Framework (Apex, LWC, docs, scripts, metadata) — Business Source License 1.1 — source-available, with a four-year clock to Apache 2.0 (the Change License).
• Standalone CI pipeline tooling under pipeline/ — MIT License, licensed separately so subscribers and CI vendors can adopt it without inheriting BSL terms.
• Third-party-derived files — KernDX includes Apache 2.0 derivatives (apex-lang, apex-trigger-actions-framework), MIT derivatives (ApexLogger, SObjectIndex, JsonPath), BSD 3-Clause derivatives (Apex-Util describe + unit-of-work utilities), and CC0-1.0 derivatives (streaming-monitor). Each derived file's header carries an SPDX-License-Identifier and upstream attribution; NOTICES.md is the per-upstream-project attribution document; the LICENSE carve-out section enumerates the Apache-2.0 / MIT / BSD-3-Clause files (CC0-1.0 derivatives are relicensed under BSL 1.1 since CC0 imposes no requirement). Full upstream license texts ship under LICENSES/.

AI coding assistants

If you're an AI coding assistant operating in this repository, read AGENTS.md and the code conventions before generating code. They define the framework rules + style that override generic defaults.