The future is not AI writing better code. It is AI not needing to write code.
A 5-screen app and a 500-screen app have the same host file in Mythik. The difference is just rows in a database.
┌─────────────────────────────────────────────────────────────────┐
│ Host file (App.tsx) — small, stable │
│ └─ <MythikApp specStore={…} appSpec={…} /> │
└──────────────────────────┬──────────────────────────────────────┘
│ fetches at runtime
▼
┌─────────────────────────────────────────────────────────────────┐
│ Spec store (Supabase / SQL / file / memory) │
│ • home.spec.json • task-manager.spec.json │
│ • settings.spec.json • api-spec.json │
│ • app-spec.json • … │
│ │
│ Every change is a versioned, queryable row. │
└─────────────────────────────────────────────────────────────────┘
▲
│ patches (RFC 6902) via mythik CLI
│
┌──────────┴──────────┐
│ Human • AI agent │
└─────────────────────┘
Mythik is available as an early public release. The packages below are the npm publish surface.
Mythik is a contract runtime for apps and APIs. Screens, actions, backend endpoints, editor workflows, version history, and diagnostics live as validated JSON in your store. The host app stays small and stable; the contract changes.
That is the shift: AI does not have to rewrite your application code to change what the product does. It reads the contract, patches the contract, validates the contract, and, with Reveal, asks the running app what actually happened.
The source of truth is a JSON document in a database, not code in a
repo. A "screen" is a row, not a .tsx file. Changing what users see
is editing data, not deploying code.
A spec change — new screen, new field, new validation rule, new action,
new theme token — ships in milliseconds: a mythik patch writes the
new version, the next fetch picks it up, no rebuild, no CDN bust, no
deploy.
Your favorite AI agent can drive Mythik end-to-end, but Mythik does not depend on prompt folklore. The framework ships the operating model the agent needs: bundled docs that match the installed runtime, project-local Agent Protocol files, machine-readable diagnostics, and a CLI/programmatic API built for small validated patches.
Mythik teaches Mythik to the AI. agent init installs the local
workflow into AGENTS.md or CLAUDE.md; agent context summarizes
the active store; manifest and elements let the agent read only
what it needs; patch --from-file --author writes through the
validation gate.
Reveal completes the loop. When the app is running, Mythik can expose its live contract, state, actions, diagnostics, environment, and render errors as structured context through a local Reveal Bridge, so the agent fixes what the app is actually doing instead of guessing from source files or stale screenshots.
Every change is validated before it can take effect. A patch that
breaks the contract is rejected before any state changes. A
mythik promote dev → production that produces an inconsistent state
is rejected before the pointer moves.
There is no half-baked deployment. Atomic, or nothing.
Three intersecting problems with how AI builds software today.
AI slop. Generative AI produces apps that look like apps but don't survive contact with reality: hallucinated state shape, forms that don't validate, no audit trail. The fundamental issue: AI generates code, which is opaque. Reviewers see a blob and can't tell what changed last week.
UI is mostly tedium. Define a form, lay out fields, wire validation, hook to API, handle errors, write tests, ship. Repeat 500 times. The skill ceiling is low; the labor cost is high.
Governance is an afterthought. Once an app ships, every change is risky. There's no atomic promote-with-validation. Rollbacks rewrite history. Different environments diverge over time. The team accepts this because doing it right is expensive — except it's not, if the framework is designed for it from day zero.
Mythik's bet: if the validated JSON contract is the source of truth instead of generated code, all three problems collapse into one. AI doesn't generate "the app" — it patches the contract Mythik can prove. UI tedium disappears because the spec is ~10× shorter than the code it replaces. Governance is built into the framework. And because each spec is its own document, the blast radius of any change is contained: a bad edit on one screen cannot break another.
The core Mythik interaction is not "generate an app." It is a tight, auditable loop where the agent reads the contract, patches the contract, validates the contract, and verifies reality.
agent context
|
v
manifest -> elements -> patch --from-file --author -> validate -> verify
^ | |
| v v
| structured diagnostics manifest / elements
| history / Reveal
+---------------------- refine and retry ----------------------+
Every step is shaped for AI work. manifest gives structure without
dumping the whole spec. elements reads only the nodes that matter.
--toon trims token weight for large reads. patch carries a small
RFC 6902 diff instead of a full-document rewrite. Errors return paths,
rule IDs, and suggestion text the agent can use for the next attempt.
Self-correction is built into the gate. When a patch breaks the
contract, Mythik rejects it before persistence. The agent reads the
diagnostics, refines the patch, and retries. When the patch passes,
validate and verify close the loop. Verification can be structural
(manifest, elements, history) or live (reveal current,
reveal screen, reveal element) when a running app is available.
For drafts and candidates outside the stored-spec loop, mythik lint --from-file <draft>.json and mythik validate <spec-id> run the same
validators read-only. The result is fast iteration without half-baked
writes.
Mythik Reveal gives AI agents structured runtime context from the app that is actually running: mounted screens, resolved props, selected state, events, diagnostics, and render errors.
When an app misbehaves, a fresh agent usually guesses from stale specs, screenshots, logs, or source files. Reveal changes that loop: the app can expose its live contract through a local, token-protected bridge, so the agent asks the runtime what actually mounted before proposing a patch.
A Reveal context can include:
- the active renderer and environment
- the mounted spec summary
- selected screen or element context
- resolved public props and element dependencies
- included state paths, with redaction
- render errors, warnings, action/dataSource events, and diagnostics
- patch target metadata when the runtime can identify a versioned spec
Start the local bridge:
npx mythik reveal start --port 17373Pass the printed MYTHIK_REVEAL_URL and MYTHIK_REVEAL_TOKEN into
your development host:
const reveal = React.useMemo(() => ({
enabled: import.meta.env.DEV,
appName: 'my-app',
bridgeUrl: import.meta.env.VITE_MYTHIK_REVEAL_URL,
token: import.meta.env.VITE_MYTHIK_REVEAL_TOKEN,
environment: { id: 'dev', source: 'host' as const },
includeStatePaths: ['/ui', '/form'],
redactStatePaths: ['/auth', '/secrets'],
}), []);
<MythikApp appSpec={appSpec} specStore={specStore} reveal={reveal} />;Then inspect the running app:
npx mythik reveal apps --json
npx mythik reveal context --app my-app
npx mythik reveal current --app my-app
npx mythik reveal screen dashboard --app my-app
npx mythik reveal element submit-button --app my-appReveal is development tooling. Keep it disabled in production, never commit Reveal tokens, and include only the state paths an agent needs. The point is simple: Mythik Reveal makes runtime truth available before the agent invents a theory.
Here's what an AI agent does to add a "due date" column to a task
list. The example uses the live mythik CLI; output is illustrative.
In a real project, agent init and agent context are usually already
in place before the edit begins.
# 0. Load the project's Mythik operating context
$ npx mythik agent context --app task-app --include-screens --out .mythik/agent/context.md
# 1. Read the stored contract (cheap; no patch yet)
$ npx mythik manifest task-manager
screen: layout (45 elements)
root: layout (box)
├── header (box)
├── task-list (list) → bound to /tasks
│ └── task-row (box)
│ ├── title (text)
│ ├── priority (select)
│ └── status (text)
└── new-task-form (box)
├── title-input (input)
├── priority-select (select)
└── submit-btn (button)
# 2. Read just the elements you need (use --toon for token-efficient output)
$ npx mythik elements task-manager task-row,new-task-form --json
{
"task-row": { "type": "box", "children": ["title","priority","status"] },
"new-task-form": { "type": "box", "children": [...] }
}
# 3. Compose a patch (RFC 6902)
$ cat add-due-date.json
[
{ "op": "add", "path": "/elements/due-date",
"value": { "type": "text", "props": { "content": "${due_date}" } } },
{ "op": "add", "path": "/elements/task-row/children/-",
"value": "due-date" },
{ "op": "add", "path": "/elements/due-input",
"value": { "type": "input", "props": { "kind": "date", "bind": "/draft/due_date" } } },
{ "op": "add", "path": "/elements/new-task-form/children/-",
"value": "due-input" }
]
# 4. Patch through the atomic validation gate
$ npx mythik patch task-manager --from-file add-due-date.json --author claude
✓ Patch applied. v3 -> v4. 4 elements modified.
# 5. Validate and ask the running app what it mounted
$ npx mythik validate task-manager
✓ Valid.
$ npx mythik envs task-manager --set dev=4 --author claude
$ npx mythik reveal screen task-manager --app task-app --json
{ "renderErrors": [], "warnings": [], "screen": { "id": "task-manager" } }
# 6. Promote when ready
$ npx mythik promote task-manager --from dev --to production --confirm --author mldix
✓ Validated against contract.
✓ Cross-screen consistency check passed.
✓ Pointer moved: production v3 -> v4.
Live in production: 0 ms.No rebuild. No CI. No deploy. The next user to load task-manager
sees the new column. History records what changed, who changed it,
and when. Reveal confirms what the running app mounted. The version is
queryable, replayable, rollbackable to any previous state without
rewriting history.
The CLI output above is what a human types. An AI agent does the same
thing through mythik-cli/api, with structured input/output, no shell
escaping. The loop has the same shape for both.
Five properties that fall out of treating the spec as the source of truth.
Mythik does not assume a human will sit beside every fresh agent and
explain the framework. agent init and agent context put the
operating contract inside the project: what store is active, which
files are drafts, how to patch, when to lint, when to use Reveal, and
how to verify the result.
The framework carries its own workflow.
Traditional debugging asks the agent to infer behavior from code and screenshots. Reveal lets the app answer directly with structured runtime context: current screen, selected element, resolved props, included state, events, render errors, warnings, and diagnostics.
The running app becomes part of the agent's context window.
Every change to a spec creates a new immutable row in screen_versions.
Versions are stored as snapshot+patch chains: every Nth version is a
full snapshot, the rest are RFC 6902 patches replayed against the
nearest snapshot. History is queryable with structural diffs:
$ npx mythik history task-manager
v4 (claude, 2026-05-06, patch) "Add due date column"
+ element "due-date" added
+ element "due-input" added
~ task-row.children: ["title","priority","status"] → [..., "due-date"]
v3 (alice, 2026-05-04, patch) "Reorder priority field"
~ task-row prop position: "after-title" → "before-status"
v2 (alice, 2026-04-24, push) "Add priority field"
v1 (system, 2026-04-23, push) "Initial spec"Rollback is always-forward: rollback creates a new version
whose content equals the target. History is never rewritten.
dev, staging, production are not deploy targets — they are rows
in screen_environments that point at a specific version of a spec.
Promotion moves a pointer, atomically, after running:
- Structural validation of the source version
- Cross-screen consistency (all referenced specs/actions exist)
- AppSpec/ApiSpec contract validation
If any check fails, the gate rejects and the pointer doesn't move. There is no "partial promotion."
This means: experiments are environments. Multi-tenancy is environments. Per-customer variation is environments. No deploy required for any of these.
The same spec model — primitives, validation rules, action chains,
expressions, $token/$state/$template references — covers screens,
forms, AppSpec, ApiSpec, identity tokens, presets, translations, editor
sessions, and the backend REST contract.
mythik contract --app app-demo --api api-demo cross-validates that
every API call a frontend makes corresponds to a real endpoint, with
matching request/response shapes, before deploy. No more frontend
shipped against an old API contract.
For a React app:
npm install mythik mythik-react
npm install -D mythik-cliFor React Native and Expo (public preview):
npm install mythik mythik-react-nativeExpo SDK 52, 53, and 54 are the tested native line. Native peer
packages are installed with npx expo install so Expo selects versions
compatible with your SDK; see
mythik-react-native for the full native
setup checklist.
For a Mythik-backed REST server:
npm install mythik-serverFor SQL-backed spec stores and servers, Mythik supports SQL Server,
PostgreSQL, MySQL, and SQLite through the mythik/server SQL boundary:
npm install mythik mythik-server
npm install pg # PostgreSQL
npm install mysql2 # MySQL
npm install mssql # SQL Server
npm install better-sqlite3 # SQLite
npx mythik init-store --dialect sqlite --target ./mythik.db
npx mythik init-store --dialect postgres --dry-runSQL adapters are optional peer dependencies. Install only the driver
for the database you actually use. SQLite uses the native
better-sqlite3 adapter; warnings from its transitive native-build
helpers are adapter-level install noise, not a Mythik runtime failure.
If a SQL adapter is missing at runtime, Mythik reports the package name
and exact npm install ... command required for the selected dialect.
MySQL generated upsert SQL targets MySQL 8.0.19+.
import { MemorySpecStore, type AppSpec, type Spec } from 'mythik';
import { MythikApp } from 'mythik-react';
const appSpec: AppSpec = {
type: 'app',
name: 'Demo App',
navigation: { type: 'tabs', initialScreen: 'home' },
screens: { home: { label: 'Home' } },
layout: {
root: 'app-shell',
elements: {
'app-shell': {
type: 'box',
props: { style: { minHeight: '100vh', padding: 24 } },
children: ['outlet'],
},
outlet: { type: 'screen-outlet' },
},
},
};
const homeSpec: Spec = {
root: 'root',
elements: {
root: {
type: 'box',
props: { style: { padding: 24 } },
children: ['title'],
},
title: {
type: 'text',
props: { content: 'Hello from Mythik', variant: 'heading' },
},
},
};
const specStore = new MemorySpecStore({ home: homeSpec });
export default function App() {
return <MythikApp appSpec={appSpec} specStore={specStore} />;
}This renders a full Mythik app with one screen. Replace MemorySpecStore
with SupabaseSpecStore or with SqlSpecStore from mythik/server
backed by SQL Server, PostgreSQL, MySQL, or SQLite. The host file does
not change as the app grows.
| Package | Purpose | Status |
|---|---|---|
mythik |
Core runtime: spec types, validation, expressions, actions, stores, versioning, editor sessions | published |
mythik-react |
React renderer, app shell, primitive registry with 38 built-ins | published |
mythik-cli |
The mythik command + programmatic CLI API. Agent Protocol, patch workflow, validation, versioning, environments, Reveal |
published |
mythik-server |
Declarative REST server from an ApiSpec — auth, RLS, catalogs, CRUD |
published |
mythik-react-native |
React Native and Expo renderer with an explicit primitive support matrix | public preview |
Each package's README focuses on its specific role within the framework. Read them for installation specifics and per-package examples.
The mythik binary is how humans and agents operate the contract
without guessing. It reads structure, applies small validated patches,
moves environment pointers, and exposes runtime truth through Reveal.
The canonical workflow:
npx mythik manifest <spec-id> # read structure
npx mythik elements <spec-id> <ids> # read specific elements
npx mythik patch <spec-id> --from-file patch.json --author <agent> # versioned RFC 6902 patch
npx mythik validate <spec-id> # standalone validation
npx mythik envs <spec-id> --set dev=N # move dev pointer
npx mythik promote <spec-id> --from dev --to production --confirm
npx mythik history <spec-id> # version history
npx mythik diff <spec-id> <from> <to> # structural diffUse --json for machine-readable output and --toon (where supported)
for token-efficient agent workflows.
Mythik teaches Mythik to the AI.
The goal is not to make every human memorize the framework's operating rules. The goal is to make the project carry those rules with it. Agent Protocol turns Mythik's workflow into local instructions the agent reads before it edits anything: where the source of truth lives, how to inspect a spec, how to patch safely, when to lint, when to use Reveal, and how to verify the result.
Without it, a fresh agent may treat Mythik like ordinary JSON: pull the whole spec, rewrite a local file, push it back, and accidentally bypass the workflow that makes Mythik safe.
agent init codexcreates/updatesAGENTS.md.agent init claudecreates/updatesCLAUDE.md.agent init allcreates/updates both files.
agent init does not overwrite your whole agent file. It inserts or
replaces only the Mythik-managed block between
<!-- mythik-agent-protocol:start --> and
<!-- mythik-agent-protocol:end -->, preserving any instructions you
keep outside that block.
The adapter files point the agent to shared .mythik/agent/*
instructions: context.md, protocol.md, commands.md, reveal.md,
and safety.md. Those files capture the canonical edit loop,
source-of-truth rules, lint scope, TOON guidance, Reveal usage, and
safety constraints.
Run one agent init target for your agent, then refresh the project
context file from the active Mythik store:
npx mythik agent init codex
npx mythik agent context --app <app-id> --include-screens --out .mythik/agent/context.mdFor Claude, use npx mythik agent init claude; for both, use
npx mythik agent init all.
Existing stored specs use the required loop:
manifest -> elements -> patch --from-file --author -> validate -> verify
The active Mythik store is the source of truth. Local spec files are
drafts, snapshots, migrations, backups, or fixtures unless a file store
is intentionally configured. Use TOON for token-efficient reads when
supported, for example mythik elements <id> <target-ids> --toon. Use
lint before first-pushing local drafts, replacement files, bulk
imports/migrations, and relevant consumer code changes.
npx mythik docs path # locate bundled AI documentation
npx mythik docs copy ./mythik-docs # copy AI docs into project rootProgrammatic use bypasses shell quoting:
import { readFile } from 'node:fs/promises';
import { runPatch } from 'mythik-cli/api';
const patches = JSON.parse(await readFile('patch.json', 'utf8'));
await runPatch('task-manager', patches, {
store,
author: 'agent-name',
json: true,
});Mythik documentation is part of the product, not an external website a fresh agent may or may not find. It ships inside the npm package, so the framework knowledge an agent reads matches the runtime your project installed.
Use docs path for the full bundled corpus:
npx mythik docs path
# /your/project/node_modules/mythik/docsCopy it into a project when you want a visible local reference:
npx mythik docs copy ./mythik-docsUse Agent Protocol when you want Mythik to teach the local workflow to the AI:
npx mythik agent init codex
npx mythik agent init claude
npx mythik agent context --app <app-id> --include-screens --out .mythik/agent/context.mdagent init creates or updates AGENTS.md and CLAUDE.md through a
Mythik-managed block, preserving your own project instructions outside
that block. agent context writes the current store, app, screens,
commands, safety rules, and Reveal guidance into .mythik/agent/ so a
fresh agent starts with the framework's operating model already loaded.
Inside node_modules/mythik/docs/:
consumer/ai-context.md— spec-generation primer (rules and traps)consumer/ai-context-primitives.md— every primitive's propsconsumer/ai-context-runtime-semantics.md— render-time behaviorconsumer/reference-doc.md— full rule catalogwiki/compiled/— atomic per-concept articles (one page per action, primitive, rule, expression) optimized for AI lookupllms.txt— index for AI tools that read it
The wiki is generated from the canonical consumer docs. It is not edited directly. The docs explain the framework; Agent Protocol turns that knowledge into project-local operating instructions; Reveal lets the running app add live truth when the agent needs to debug behavior.
The core, React, CLI, server, and React Native packages are the npm
publish surface. mythik-react-native follows the same version line as
the rest of Mythik, but remains a public preview while native primitive
parity and smoke coverage continue to expand. It ships with an explicit
support matrix, and native milestone primitives remain outside the
supported surface until their platform adapters are complete.
The framework is shipped for real-world feedback. APIs are documented and stable enough to build production apps; expect refinements as patterns emerge.
Release notes and patch details are published in the CHANGELOG and on GitHub Releases.
Apache-2.0.