anhedral 0.4.2 → 0.6.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +35 -265
- package/assets/anhedral-cli-init-technical.svg +322 -0
- package/assets/anhedral-cli-init.svg +257 -173
- package/dist/bin.js +28 -191
- package/dist/dependencies.d.ts +7 -57
- package/dist/dependencies.js +96 -308
- package/dist/index.d.ts +2 -7
- package/dist/index.js +1 -4
- package/dist/platforms/desktop.js +401 -0
- package/dist/platforms/extension.js +401 -0
- package/dist/platforms/mobile.js +232 -0
- package/dist/project.d.ts +0 -26
- package/dist/standard-products.d.ts +2 -0
- package/dist/standard-products.js +6 -0
- package/dist/standard.d.ts +18 -0
- package/dist/standard.js +595 -0
- package/dist/version.d.ts +1 -1
- package/dist/version.js +1 -1
- package/docs/application-stack-standard.md +700 -0
- package/package.json +29 -51
- package/CHANGELOG.md +0 -178
- package/CONTRIBUTING.md +0 -77
- package/SECURITY.md +0 -37
- package/SKILL.md +0 -339
- package/assets/images/svg/ably-symbol-color.svg +0 -8
- package/bin/anhedral.js +0 -2
- package/dist/architecture/contributions.d.ts +0 -28
- package/dist/architecture/contributions.js +0 -125
- package/dist/architecture/index.d.ts +0 -12
- package/dist/architecture/index.js +0 -6
- package/dist/architecture/manifest.d.ts +0 -53
- package/dist/architecture/manifest.js +0 -283
- package/dist/architecture/modules.d.ts +0 -41
- package/dist/architecture/modules.js +0 -187
- package/dist/architecture/plan.d.ts +0 -58
- package/dist/architecture/plan.js +0 -145
- package/dist/architecture/templates.d.ts +0 -10
- package/dist/architecture/templates.js +0 -23
- package/dist/cli.d.ts +0 -32
- package/dist/cli.js +0 -281
- package/dist/composers/root.d.ts +0 -6
- package/dist/composers/root.js +0 -35
- package/dist/print.d.ts +0 -8
- package/dist/print.js +0 -48
- package/dist/prompts.d.ts +0 -6
- package/dist/prompts.js +0 -41
- package/dist/scaffold.d.ts +0 -64
- package/dist/scaffold.js +0 -2102
- package/dist/template-source.d.ts +0 -20
- package/dist/template-source.js +0 -180
- package/dist/templates/api.d.ts +0 -2
- package/dist/templates/api.js +0 -3187
- package/dist/templates/assets-private-proxy.d.ts +0 -3
- package/dist/templates/assets-private-proxy.js +0 -277
- package/dist/templates/desktop.js +0 -792
- package/dist/templates/electron-updater.d.ts +0 -3
- package/dist/templates/electron-updater.js +0 -358
- package/dist/templates/extension.js +0 -856
- package/dist/templates/first-run.d.ts +0 -2
- package/dist/templates/first-run.js +0 -167
- package/dist/templates/mobile.js +0 -861
- package/dist/templates/shared.d.ts +0 -2
- package/dist/templates/shared.js +0 -577
- package/dist/templates/web.d.ts +0 -2
- package/dist/templates/web.js +0 -569
- package/dist/toolchain.d.ts +0 -3
- package/dist/toolchain.js +0 -8
- package/dist/ui.d.ts +0 -33
- package/dist/ui.js +0 -199
- package/dist/workspace-config.d.ts +0 -11
- package/dist/workspace-config.js +0 -372
- package/docs/NORTHSTAR.md +0 -114
- package/docs/conventions.md +0 -94
- package/docs/engineering-principles.md +0 -88
- package/docs/master-stack-map.md +0 -199
- package/docs/output-tree-contract.md +0 -493
- package/docs/references/manual-scaffolding.md +0 -421
- package/docs/references/provisioning.md +0 -577
- package/scripts/render-master-stack-map.mjs +0 -510
- package/templates/api-fastify/apps/api/tsconfig.json +0 -20
- package/templates/catalog.json +0 -23
- package/templates/db-drizzle/packages/db/tsconfig.json +0 -14
- package/templates/desktop-electron/apps/desktop/tsconfig.json +0 -37
- package/templates/extension-wxt/apps/extension/tsconfig.json +0 -41
- package/templates/mobile-expo/apps/mobile/expo-env.d.ts +0 -1
- package/templates/web-next/apps/web/next-env.d.ts +0 -6
- /package/dist/{templates → platforms}/desktop.d.ts +0 -0
- /package/dist/{templates → platforms}/extension.d.ts +0 -0
- /package/dist/{templates → platforms}/mobile.d.ts +0 -0
package/docs/NORTHSTAR.md
DELETED
|
@@ -1,114 +0,0 @@
|
|
|
1
|
-
# Anhedral DX north star
|
|
2
|
-
|
|
3
|
-
## One command in. A working product foundation out.
|
|
4
|
-
|
|
5
|
-
Anhedral should let a developer choose the surfaces and capabilities their idea
|
|
6
|
-
needs, generate one understandable TypeScript workspace, and reach a working
|
|
7
|
-
feature without first becoming an expert in every framework and provider.
|
|
8
|
-
|
|
9
|
-
The generated application must feel like a project the developer wrote
|
|
10
|
-
themselves:
|
|
11
|
-
|
|
12
|
-
- ordinary framework source, package scripts, environment files, and tests;
|
|
13
|
-
- one shared contract and API client across every selected surface;
|
|
14
|
-
- working vertical slices instead of disconnected demonstrations;
|
|
15
|
-
- safe, inspectable structural changes with no hidden runtime or control plane;
|
|
16
|
-
- a clear path from first run to production without changing architecture; and
|
|
17
|
-
- built-in scale through managed, autoscaling providers rather than custom
|
|
18
|
-
infrastructure.
|
|
19
|
-
|
|
20
|
-
Anhedral succeeds when developers spend their time on the product idea, not on
|
|
21
|
-
repeating setup, reconciling integrations, or reverse-engineering generated
|
|
22
|
-
code.
|
|
23
|
-
|
|
24
|
-
## Product principles
|
|
25
|
-
|
|
26
|
-
### Fast to first value
|
|
27
|
-
|
|
28
|
-
A developer should understand the choices before generation, see the resolved
|
|
29
|
-
dependency closure, and know the next command when generation finishes.
|
|
30
|
-
`pnpm first-run` prepares local configuration without overwriting it.
|
|
31
|
-
`pnpm ready` answers whether required configuration is complete without
|
|
32
|
-
revealing values. `pnpm verify` proves the source and selected integrations
|
|
33
|
-
build.
|
|
34
|
-
|
|
35
|
-
### Build once, ship everywhere
|
|
36
|
-
|
|
37
|
-
Contracts, validation, API calls, authentication, persistence, and product
|
|
38
|
-
behavior should be shared where the platforms permit it. Every selected client
|
|
39
|
-
should receive an idiomatic UI for the same starter feature so the developer can
|
|
40
|
-
prove the whole path on web, iOS, Android, desktop, and browser extension
|
|
41
|
-
surfaces before replacing it with their idea.
|
|
42
|
-
|
|
43
|
-
### Explicit composition
|
|
44
|
-
|
|
45
|
-
The CLI must distinguish what the developer requested from what dependencies
|
|
46
|
-
added. Interactive and automated use must produce the same canonical module
|
|
47
|
-
closure. Complete-stack generation is explicit with `--all`; focused stacks
|
|
48
|
-
remain first-class.
|
|
49
|
-
|
|
50
|
-
### Safe evolution
|
|
51
|
-
|
|
52
|
-
`add`, `ui add`, and `upgrade` must be transactional, previewable, deterministic,
|
|
53
|
-
and ownership-aware. They may merge known configuration and replace unmodified
|
|
54
|
-
managed substrate, but must never silently overwrite product code. `doctor`
|
|
55
|
-
must explain drift and give a concrete recovery action.
|
|
56
|
-
|
|
57
|
-
### Production-shaped from the start
|
|
58
|
-
|
|
59
|
-
Development and production use the same package boundaries and provider
|
|
60
|
-
integrations. Environment examples may contain placeholders, but generated
|
|
61
|
-
applications must identify them before launch. Secrets stay server-side and
|
|
62
|
-
uncommitted. Deployment guidance is specific to the selected stack and does not
|
|
63
|
-
claim resources already exist.
|
|
64
|
-
|
|
65
|
-
### Human and automation parity
|
|
66
|
-
|
|
67
|
-
Human output should be concise and actionable. `--json` should provide one clean,
|
|
68
|
-
stable document with the same resolved modules, plans, outcomes, and next steps
|
|
69
|
-
for CI and coding agents. Noninteractive commands must never depend on a prompt.
|
|
70
|
-
|
|
71
|
-
### Source ownership is the feature
|
|
72
|
-
|
|
73
|
-
Generated product seams are user-owned and readable. Provider substrate is
|
|
74
|
-
managed only where consistency and security require it. The manifest records
|
|
75
|
-
the boundary, and every lifecycle command honors it.
|
|
76
|
-
|
|
77
|
-
## Journey contract
|
|
78
|
-
|
|
79
|
-
| Journey | The developer should experience | Acceptance signal |
|
|
80
|
-
| --- | --- | --- |
|
|
81
|
-
| Discover | Immediately understand cross-platform scope, modularity, cost posture, and ownership | README states the value plainly and links to exact commands |
|
|
82
|
-
| Choose | See app surfaces, capabilities, dependencies, and runtime requirements before writes | Interactive confirmation and `--help` show the canonical resolved stack |
|
|
83
|
-
| Create | Receive deterministic source, optional Git initialization, visible installation progress, and exact next steps | `new`, `init`, dry-run, JSON, skip-install, and Git variants are tested |
|
|
84
|
-
| Configure | Safely create only missing local environment files and identify every unresolved placeholder without printing secrets | `pnpm first-run` is idempotent; `pnpm ready` returns a truthful exit status |
|
|
85
|
-
| Prove | Exercise a real contract → database → API → client → UI feature on every selected surface | Focused and complete generated stacks typecheck, test, and build |
|
|
86
|
-
| Develop | Know where product code belongs and use each framework normally | Generated README, development guide, stack map, and coding-agent skill agree |
|
|
87
|
-
| Extend | Preview and add modules or source-owned UI without losing edits | Dry-run and apply plans are deterministic, transactional, and ownership-safe |
|
|
88
|
-
| Diagnose | Understand generator drift, configuration readiness, and recovery actions | `pnpm ready` reports configuration blockers; `doctor` reports structural issues and actionable recommendations |
|
|
89
|
-
| Upgrade | Move supported projects forward without replacing product seams | Upgrade is transactional, no-op when current, and tested from supported versions |
|
|
90
|
-
| Ship | Follow selection-specific steps from previews to production and stores | Generated production guide and exact package scripts cover every selected target |
|
|
91
|
-
| Automate | Consume stable output and releases without scraping terminal prose | JSON remains parseable; successful `main` CI prepares the next patch release |
|
|
92
|
-
|
|
93
|
-
## Definition of done
|
|
94
|
-
|
|
95
|
-
A change is complete only when:
|
|
96
|
-
|
|
97
|
-
1. focused and complete module topologies generate deterministically;
|
|
98
|
-
2. generated environment setup is idempotent and readiness checks are truthful;
|
|
99
|
-
3. the shared starter feature reaches every selected compatible client;
|
|
100
|
-
4. generated code typechecks, tests, builds, and passes runtime acceptance where
|
|
101
|
-
the platform is available;
|
|
102
|
-
5. dry-run, JSON, no-op, failure, rollback, and recovery paths are covered;
|
|
103
|
-
6. source ownership survives `add`, `ui add`, and `upgrade`;
|
|
104
|
-
7. packed npm output behaves the same as repository source;
|
|
105
|
-
8. security, dependency, secret, PII, source-hygiene, and release-policy checks
|
|
106
|
-
pass; and
|
|
107
|
-
9. documentation describes the behavior that was actually verified.
|
|
108
|
-
|
|
109
|
-
## Deliberate boundaries
|
|
110
|
-
|
|
111
|
-
Anhedral does not hide provider accounts, fabricate credentials, submit paid or
|
|
112
|
-
review-gated releases, run a proprietary application runtime, or own product
|
|
113
|
-
code after generation. Those boundaries keep the output understandable,
|
|
114
|
-
portable, and under the developer's control.
|
package/docs/conventions.md
DELETED
|
@@ -1,94 +0,0 @@
|
|
|
1
|
-
# Anhedral generated-project conventions
|
|
2
|
-
|
|
3
|
-
Anhedral is a deterministic stack generator. These conventions describe the readable workspace it produces; they are not a new application framework or runtime API.
|
|
4
|
-
|
|
5
|
-
## Core rule
|
|
6
|
-
|
|
7
|
-
Use the underlying tool's normal programming model. Anhedral decides where integrations meet and generates safe defaults, but developers write ordinary Next.js, Expo Router, Fastify, Drizzle, Electron, and WXT code.
|
|
8
|
-
|
|
9
|
-
## Source ownership
|
|
10
|
-
|
|
11
|
-
```text
|
|
12
|
-
apps/ deployable framework applications
|
|
13
|
-
packages/ client-safe or server-shared TypeScript packages
|
|
14
|
-
docs/ generated stack and development guidance
|
|
15
|
-
```
|
|
16
|
-
|
|
17
|
-
- `apps/web`: Next.js App Router pages, layouts, components, hooks, and web utilities.
|
|
18
|
-
- `apps/mobile`: Expo Router screens, layouts, native components, and hooks.
|
|
19
|
-
- `apps/api`: Fastify routes, services, plugins, provider clients, and server environment validation.
|
|
20
|
-
- `apps/desktop`: Electron main/preload code and sandboxed React renderer code.
|
|
21
|
-
- `apps/desktop-updater-worker`: optional read-only Cloudflare Worker serving signed Electron updates from a bound private R2 bucket.
|
|
22
|
-
- `apps/extension`: WXT entrypoints, extension components, background logic, and content scripts.
|
|
23
|
-
- `packages/contracts`: Zod schemas for data crossing HTTP boundaries.
|
|
24
|
-
- `packages/api-client`: client-safe HTTP behavior shared across frontends.
|
|
25
|
-
- `packages/db`: Drizzle schema, database access, and reviewed SQL migrations.
|
|
26
|
-
- `packages/realtime`: client-safe Ably subscription behavior when selected.
|
|
27
|
-
|
|
28
|
-
## End-to-end feature flow
|
|
29
|
-
|
|
30
|
-
```text
|
|
31
|
-
Zod contract
|
|
32
|
-
-> Drizzle schema/query or server service
|
|
33
|
-
-> Fastify route
|
|
34
|
-
-> shared API client
|
|
35
|
-
-> Next.js / Expo / Electron / WXT UI
|
|
36
|
-
```
|
|
37
|
-
|
|
38
|
-
Routes stay thin. They authenticate, validate, call a service, and return a declared contract. Business behavior and provider SDK calls live in server services. Frontends never import API services, database connections, or server environment modules.
|
|
39
|
-
|
|
40
|
-
When `electron-updater` is selected, desktop releases follow a separate delivery path: the packaged Electron main process reads generated update metadata from an HTTPS custom domain, the Worker streams known keys from its private R2 binding, and release tooling uploads signed artifacts before mutable channel metadata. Neither Cloudflare credentials nor a public bucket URL enter the desktop application.
|
|
41
|
-
|
|
42
|
-
## Database
|
|
43
|
-
|
|
44
|
-
Database-enabled projects use managed Neon Postgres. Anhedral does not generate local Postgres, Docker Compose, or an embedded database substitute.
|
|
45
|
-
|
|
46
|
-
1. Edit the user-owned `packages/db/src/app-schema.ts`; Anhedral keeps provider tables in `generated-schema.ts`.
|
|
47
|
-
2. Run `pnpm db:generate`.
|
|
48
|
-
3. Review and commit generated SQL and metadata.
|
|
49
|
-
4. Run `pnpm verify:db`.
|
|
50
|
-
5. Apply with `pnpm db:migrate` against the intended Neon branch or project.
|
|
51
|
-
|
|
52
|
-
Schema generation must not happen during an application build. Migrations are reviewed release artifacts.
|
|
53
|
-
|
|
54
|
-
## Authentication and secrets
|
|
55
|
-
|
|
56
|
-
Clerk owns identity and sessions. The API derives identity from a verified server session and never trusts a client-supplied user ID. Only variables with a framework's explicit public prefix may enter client bundles. Database, Clerk secret, R2, RevenueCat, Ably, cron, and provider credentials remain server-only.
|
|
57
|
-
|
|
58
|
-
## UI
|
|
59
|
-
|
|
60
|
-
DOM clients use source-owned shadcn/ui components. Expo uses React Native Reusables with the selected NativeWind or Uniwind configuration.
|
|
61
|
-
|
|
62
|
-
```sh
|
|
63
|
-
pnpm anhedral:ui button dialog
|
|
64
|
-
pnpm anhedral:ui data-table --target web
|
|
65
|
-
```
|
|
66
|
-
|
|
67
|
-
Generated UI files are application source and can be customized. Preserve accessibility, keyboard/focus behavior, and platform conventions.
|
|
68
|
-
|
|
69
|
-
## Naming
|
|
70
|
-
|
|
71
|
-
- Directories and source files use lowercase kebab-case.
|
|
72
|
-
- React component filenames use kebab-case and export PascalCase components.
|
|
73
|
-
- Hooks start with `use-`.
|
|
74
|
-
- Framework-required entrypoint names stay unchanged.
|
|
75
|
-
- Shared packages use the `@shared/<name>` namespace.
|
|
76
|
-
|
|
77
|
-
## Structural changes
|
|
78
|
-
|
|
79
|
-
Run `pnpm anhedral:doctor` before changing generated structure. Preview new modules or UI with `--dry-run`. Anhedral refuses managed-file drift, symlinks, and unowned collisions instead of overwriting source.
|
|
80
|
-
|
|
81
|
-
Application product files are developer-owned. `README.md` and `PRODUCTION.md` become user-owned after initialization. Root configuration is mergeable. Integration substrate and generated guidance are recorded in `anhedral.json`.
|
|
82
|
-
|
|
83
|
-
## Verification
|
|
84
|
-
|
|
85
|
-
Run the smallest relevant package check while iterating, then the generated root verification before handoff:
|
|
86
|
-
|
|
87
|
-
```sh
|
|
88
|
-
pnpm first-run
|
|
89
|
-
pnpm ready
|
|
90
|
-
pnpm typecheck
|
|
91
|
-
pnpm verify
|
|
92
|
-
pnpm build
|
|
93
|
-
pnpm anhedral:doctor
|
|
94
|
-
```
|
|
@@ -1,88 +0,0 @@
|
|
|
1
|
-
# The Zen of Anhedral
|
|
2
|
-
|
|
3
|
-
Anhedral applies the spirit of Tim Peters' *Zen of Python* to a TypeScript stack
|
|
4
|
-
generator. This is an engineering policy, not a preference for Python syntax.
|
|
5
|
-
The goal is generated software whose behavior, ownership, and failure modes are
|
|
6
|
-
easy to see.
|
|
7
|
-
|
|
8
|
-
## Working rules
|
|
9
|
-
|
|
10
|
-
1. **Make the result readable.** Generated source should look like ordinary,
|
|
11
|
-
idiomatic framework code. Prefer clear names and small seams over clever
|
|
12
|
-
abstractions or compressed templates.
|
|
13
|
-
2. **Make choices explicit.** Keep requested modules distinct from dependencies
|
|
14
|
-
added by resolution. Record ownership, toolchain, template provenance, and
|
|
15
|
-
planned writes. Never infer permission to replace product code.
|
|
16
|
-
3. **Keep one source of truth.** Module identity and kind belong to the
|
|
17
|
-
architecture registry. Project shape belongs to the project model. CLI,
|
|
18
|
-
templates, manifests, and docs consume those definitions instead of
|
|
19
|
-
restating them.
|
|
20
|
-
4. **Choose the smallest complete design.** A simple vertical slice is better
|
|
21
|
-
than a generic subsystem. Real provider complexity may be necessary, but it
|
|
22
|
-
must stay behind a narrow, named boundary.
|
|
23
|
-
5. **Prefer flat control flow.** Validate early, return early, and dispatch once.
|
|
24
|
-
Split orchestration, domain rules, rendering, filesystem transactions, and
|
|
25
|
-
process execution into distinct namespaces.
|
|
26
|
-
6. **Generate sparsely.** A selected stack receives what it needs. Unselected
|
|
27
|
-
apps and providers must not leave dead packages, environment variables,
|
|
28
|
-
scripts, or documentation behind.
|
|
29
|
-
7. **Treat rules uniformly.** Add module dependencies and conflicts to the
|
|
30
|
-
registry; do not scatter special-case resolution across commands. Introduce
|
|
31
|
-
an exception only when the practical behavior is clearer and it is covered
|
|
32
|
-
by a regression test.
|
|
33
|
-
8. **Never hide failure.** Invalid input, drift, child-process failure, partial
|
|
34
|
-
configuration, and unsafe writes must produce a useful error and nonzero
|
|
35
|
-
status. An intentionally ignored failure must be named, local, and tested.
|
|
36
|
-
9. **Do not guess through ambiguity.** Reject unknown commands, conflicting
|
|
37
|
-
edits, unowned collisions, unsafe paths, and unsupported project versions.
|
|
38
|
-
Interactive choices require confirmation; noninteractive behavior must be
|
|
39
|
-
deterministic.
|
|
40
|
-
10. **Provide one obvious path.** Use `new` or `init` to create, `add` for
|
|
41
|
-
modules, `ui add` for source-owned UI, `upgrade` for schema evolution, and
|
|
42
|
-
`doctor` for drift. Generated projects use `first-run`, `ready`, `verify`,
|
|
43
|
-
and then `dev`.
|
|
44
|
-
11. **Ship deliberate increments.** Finish a small explainable change now when
|
|
45
|
-
its behavior is proven. Defer a broad abstraction until it has a concrete
|
|
46
|
-
caller and an acceptance test.
|
|
47
|
-
12. **Make explanation a design test.** If a change cannot be summarized as
|
|
48
|
-
input → decision → observable result, simplify it before merging.
|
|
49
|
-
|
|
50
|
-
## Namespace boundaries
|
|
51
|
-
|
|
52
|
-
```text
|
|
53
|
-
CLI parsing and presentation
|
|
54
|
-
-> architecture and project model
|
|
55
|
-
-> scaffold orchestration and transactions
|
|
56
|
-
-> templates and configuration composers
|
|
57
|
-
-> generated framework source
|
|
58
|
-
```
|
|
59
|
-
|
|
60
|
-
- `src/architecture/` owns module resolution, plans, manifests, and composition
|
|
61
|
-
invariants.
|
|
62
|
-
- `src/project.ts` owns the template-facing project shape.
|
|
63
|
-
- `src/scaffold.ts` coordinates lifecycle operations; it must not become the
|
|
64
|
-
source of domain types or embed unrelated templates.
|
|
65
|
-
- `src/templates/` renders selected framework and lifecycle files.
|
|
66
|
-
- `src/transaction.ts` owns safe application and rollback.
|
|
67
|
-
- `src/bin.ts`, `src/cli.ts`, and `src/prompts.ts` own user input and output.
|
|
68
|
-
|
|
69
|
-
Dependencies point toward the model, not back toward the orchestrator. A
|
|
70
|
-
template may depend on `ProjectOptions`; it should not depend on the scaffold
|
|
71
|
-
command that called it.
|
|
72
|
-
|
|
73
|
-
## Review questions
|
|
74
|
-
|
|
75
|
-
Before merging, answer these plainly:
|
|
76
|
-
|
|
77
|
-
- Where is the single authoritative definition for this behavior?
|
|
78
|
-
- What input is explicit, what is derived, and is that distinction observable?
|
|
79
|
-
- Does the happy path read top-to-bottom without hidden mutation?
|
|
80
|
-
- What ambiguity or failure can occur, and how does the user see it?
|
|
81
|
-
- Does the change add output for an unselected module?
|
|
82
|
-
- Can an existing user-owned file be overwritten or silently reclassified?
|
|
83
|
-
- Is there a focused test for the rule and a broader test for the journey?
|
|
84
|
-
- Can the implementation be explained in a short paragraph?
|
|
85
|
-
|
|
86
|
-
Practicality still wins: duplicated literal output inside generated framework
|
|
87
|
-
code can be clearer than a generator-only abstraction. The burden is on an
|
|
88
|
-
abstraction to remove real ambiguity or repetition without hiding behavior.
|
package/docs/master-stack-map.md
DELETED
|
@@ -1,199 +0,0 @@
|
|
|
1
|
-
# Anhedral master stack map
|
|
2
|
-
|
|
3
|
-
This is the canonical whole-stack map for Anhedral. It shows the ordered flow
|
|
4
|
-
from skill-led planning through deterministic generation, source layout,
|
|
5
|
-
connected capabilities, cloud provisioning, command-driven operations, agent
|
|
6
|
-
experience, and production verification.
|
|
7
|
-
|
|
8
|
-

|
|
9
|
-
|
|
10
|
-
The diagram is generated from `scripts/render-master-stack-map.mjs`. Change the
|
|
11
|
-
content or geometry there, then run `pnpm docs:stack-map`; do not hand-edit the
|
|
12
|
-
SVG. The fixed-width map below remains the detailed text and accessibility
|
|
13
|
-
reference.
|
|
14
|
-
|
|
15
|
-
Read top to bottom. Arrows represent lifecycle order, not runtime network calls.
|
|
16
|
-
Runtime and provider connections are stated explicitly inside each stage.
|
|
17
|
-
|
|
18
|
-
```text
|
|
19
|
-
+==========================================================================================================================+
|
|
20
|
-
| ANHEDRAL MASTER STACK MAP |
|
|
21
|
-
+--------------------------------------------------------------------------------------------------------------------------+
|
|
22
|
-
|OUTCOME One readable TypeScript codebase and one command surface connecting every application, cloud resource, release |
|
|
23
|
-
|path, runbook, and coding agent. |
|
|
24
|
-
|PRINCIPLE Ordinary framework code, source ownership, and generated integration boundaries. Anhedral assembles the stack; |
|
|
25
|
-
|it is not the application runtime. |
|
|
26
|
-
+==========================================================================================================================+
|
|
27
|
-
|
|
|
28
|
-
v
|
|
29
|
-
+==========================================================================================================================+
|
|
30
|
-
| 1 SELECT + PLAN |
|
|
31
|
-
+--------------------------------------------------------------------------------------------------------------------------+
|
|
32
|
-
|SKILL FIRST Install and invoke $anhedral-init. Ask for project name and custom-domain status before generating or |
|
|
33
|
-
|provisioning. |
|
|
34
|
-
|CREATE anhedral new <directory> | anhedral init EXTEND anhedral add <modules> | anhedral ui add <components> |
|
|
35
|
-
|INSPECT anhedral doctor AUTOMATE --dry-run | --json | --verbose | --skip-install |
|
|
36
|
-
|SURFACES web | mobile | api | desktop | extension |
|
|
37
|
-
|FEATURES db | auth | billing | storage | native-subscriptions | electron-updater |
|
|
38
|
-
|UI shadcn/ui for DOM clients | React Native Reusables for Expo | NativeWind or Uniwind |
|
|
39
|
-
|CLOSURE auth -> api + db | billing -> auth | storage -> auth | native-subscriptions -> mobile + billing | |
|
|
40
|
-
|electron-updater -> desktop |
|
|
41
|
-
+==========================================================================================================================+
|
|
42
|
-
|
|
|
43
|
-
v
|
|
44
|
-
+==========================================================================================================================+
|
|
45
|
-
| 2 GENERATE SAFELY |
|
|
46
|
-
+--------------------------------------------------------------------------------------------------------------------------+
|
|
47
|
-
|PIPELINE Resolve modules -> select immutable templates -> verify SHA-256 catalog -> stage files -> compose typed |
|
|
48
|
-
|contributions. |
|
|
49
|
-
|PIPELINE Run pinned UI providers only in staging -> record provenance and ownership -> atomic commit -> one root pnpm |
|
|
50
|
-
|install. |
|
|
51
|
-
|REFUSES traversal | symlinks | nested repositories/workspaces | caches | oversized files | unowned collisions | managed |
|
|
52
|
-
|drift. |
|
|
53
|
-
|OWNERSHIP Product source plus README/PRODUCTION are user-owned | root configuration is mergeable | integration substrate |
|
|
54
|
-
|is managed. |
|
|
55
|
-
|STATE anhedral.json records modules, versions, template/UI provenance, styling, file hashes, modes, and ownership. |
|
|
56
|
-
|WHY Deterministic, inspectable generation and safe incremental adds without replacing user work. |
|
|
57
|
-
+==========================================================================================================================+
|
|
58
|
-
|
|
|
59
|
-
v
|
|
60
|
-
+==========================================================================================================================+
|
|
61
|
-
| 3 ONE PNPM + TURBOREPO TYPESCRIPT WORKSPACE |
|
|
62
|
-
+--------------------------------------------------------------------------------------------------------------------------+
|
|
63
|
-
|apps/web Next.js App Router + React + shadcn/ui. WHY: SSR, routing, server-first web, and source-owned UI. |
|
|
64
|
-
|apps/mobile Expo Router + React Native Reusables. WHY: one native TypeScript product for iOS and Android. |
|
|
65
|
-
|apps/api Fastify + validation/security plugins. WHY: thin routes, services, structured logs, and explicit boundaries. |
|
|
66
|
-
|apps/desktop Electron + Vite + sandboxed React renderer. WHY: cross-platform desktop with a narrow privileged bridge. |
|
|
67
|
-
|apps/extension WXT + React + MV3 entrypoints. WHY: browser permissions, side panel/background, builds, and packaging. |
|
|
68
|
-
|apps/assets-private-proxy Cloudflare Worker + private R2 binding. WHY: controlled GET/HEAD media delivery without bucket |
|
|
69
|
-
|listing. |
|
|
70
|
-
|apps/desktop-updater-worker Cloudflare Worker + private R2 binding. WHY: custom-domain Electron metadata, ranges, and |
|
|
71
|
-
|downloads. |
|
|
72
|
-
|packages/contracts Zod schemas. WHY: one validated network contract shared across every boundary. |
|
|
73
|
-
|packages/api-client Typed client-safe HTTP. WHY: one request path for web, mobile, desktop, and extension. |
|
|
74
|
-
|packages/db Drizzle schema + reviewed SQL migrations. WHY: readable TypeScript schema and explicit release artifacts. |
|
|
75
|
-
|packages/realtime Ably client. WHY: scoped invalidation events while clients refetch authoritative state. |
|
|
76
|
-
+==========================================================================================================================+
|
|
77
|
-
|
|
|
78
|
-
v
|
|
79
|
-
+==========================================================================================================================+
|
|
80
|
-
| 4 CONNECTED PRODUCT CAPABILITIES |
|
|
81
|
-
+--------------------------------------------------------------------------------------------------------------------------+
|
|
82
|
-
|REQUESTS Zod contract -> service/Drizzle query -> Fastify route -> typed API client -> every selected client. |
|
|
83
|
-
|IDENTITY Clerk sessions in clients -> verified server identity; never trust a client-supplied user ID. |
|
|
84
|
-
|DATABASE Fastify -> Drizzle -> managed Neon Postgres with isolated dev/preview/production; no generated local Postgres. |
|
|
85
|
-
|STORAGE API presigns R2 PUT -> client uploads -> API confirms -> Worker streams confirmed assets or owner-authorized |
|
|
86
|
-
|reads. |
|
|
87
|
-
|BILLING Expo purchase -> RevenueCat -> signed webhook -> Neon entitlement + transactional outbox. |
|
|
88
|
-
|REALTIME Outbox -> scoped Ably event -> every client refetches the authoritative entitlement. |
|
|
89
|
-
|DESKTOP UPDATE Signed native build -> artifacts then latest metadata -> private R2 -> updates.<domain> Worker -> |
|
|
90
|
-
|electron-updater. |
|
|
91
|
-
|SECURITY Server-only secrets | exact CORS | rate limits/headers | Electron isolation | least privilege | private buckets. |
|
|
92
|
-
+==========================================================================================================================+
|
|
93
|
-
|
|
|
94
|
-
v
|
|
95
|
-
+==========================================================================================================================+
|
|
96
|
-
| 5 PROVISION + CONFIGURE THE CLOUD |
|
|
97
|
-
+--------------------------------------------------------------------------------------------------------------------------+
|
|
98
|
-
|DOMAIN Buy/confirm domain -> add Cloudflare zone -> preserve mail records -> delegate nameservers -> activate DNSSEC. |
|
|
99
|
-
|GITHUB + CI Organization repository, protected environments, pinned Actions, PR checks, branches, and release artifacts. |
|
|
100
|
-
|NEON Projects/branches per environment, pooled DATABASE_URL, backups, reviewed migrations, and controlled deploy gates. |
|
|
101
|
-
|CLERK Development/production instances, publishable/secret keys, domains, OAuth, redirects, webhooks, native and CRX IDs. |
|
|
102
|
-
|CLOUDFLARE Authoritative DNS, private R2 buckets, scoped tokens, CORS/lifecycle, Worker bindings, logs, and custom |
|
|
103
|
-
|domains. |
|
|
104
|
-
|VERCEL Services deployment for web/API, rewrites, environment scopes, preview/production, cron endpoints, domains, and |
|
|
105
|
-
|TLS. |
|
|
106
|
-
|REVENUECAT + ABLY Products, offerings, entitlements, store credentials, signed webhook, scoped realtime, and retry cron. |
|
|
107
|
-
|EAS + STORES Expo project, credentials, internal builds, TestFlight/Play testing, metadata, privacy, review, and rollout. |
|
|
108
|
-
|BROWSER STORE Stable extension ID, least host permissions, OAuth sync, privacy disclosure, trusted testing, and review. |
|
|
109
|
-
|DESKTOP Native-OS signing/notarization, electron-builder installers, private update channel, upgrade tests, and rollback. |
|
|
110
|
-
|DNS app.<domain> points from Cloudflare DNS to Vercel and stays DNS-only; assets/updates are Cloudflare Worker Custom |
|
|
111
|
-
|Domains. |
|
|
112
|
-
|AGENT STOPS User handles sign-in/MFA, purchases, secret generation/reveal, destructive confirmations, and final |
|
|
113
|
-
|submissions. |
|
|
114
|
-
+==========================================================================================================================+
|
|
115
|
-
|
|
|
116
|
-
v
|
|
117
|
-
+==========================================================================================================================+
|
|
118
|
-
| 6 GENERATED package.json COMMAND SURFACE |
|
|
119
|
-
+--------------------------------------------------------------------------------------------------------------------------+
|
|
120
|
-
|WORKSPACE dev | build | typecheck | verify WHY: run and validate exactly the selected monorepo. |
|
|
121
|
-
|APP LOOPS dev:web | dev:mobile | dev:api | dev:desktop | dev:extension |
|
|
122
|
-
|APP CHECKS verify:web | verify:mobile | verify:api | verify:desktop | verify:extension |
|
|
123
|
-
|VERCEL deploy:vercel:{link,preview,production,inspect,domain:inspect} WHY: connect, release, diagnose, and configure DNS. |
|
|
124
|
-
|MOBILE mobile:eas:{login,init} | mobile:build:{internal,production}:{ios,android} | mobile:submit:{ios,android} |
|
|
125
|
-
|DATABASE neon:{login,project:create} | db:{generate,migrate,check,studio} | verify:db |
|
|
126
|
-
|STORAGE r2:{login,bucket:create,cors:list,cors:set} | assets:proxy:{check,dev,deploy} | verify:assets-proxy |
|
|
127
|
-
|UPDATES desktop:updates:{cloudflare:login,bucket:create,provision,publish} |
|
|
128
|
-
|UPDATES desktop:updates:worker:{check,dev,deploy,types} | desktop:updates:build:{mac,win,linux} | verify:desktop-updates |
|
|
129
|
-
|DESKTOP desktop:build | verify:desktop EXTENSION extension:zip | verify:extension |
|
|
130
|
-
|STRUCTURE anhedral doctor | add/ui --dry-run WHY: detect drift and preview safe structural changes. |
|
|
131
|
-
+==========================================================================================================================+
|
|
132
|
-
|
|
|
133
|
-
v
|
|
134
|
-
+==========================================================================================================================+
|
|
135
|
-
| 7 DEVELOPER, AGENT + COMPUTER-USE EXPERIENCE |
|
|
136
|
-
+--------------------------------------------------------------------------------------------------------------------------+
|
|
137
|
-
|DOCS README.md first run/source map | docs/DEVELOPMENT.md recipes | docs/STACK.md tool map | PRODUCTION.md cloud runbook. |
|
|
138
|
-
|CONTROL SKILL.md agent workflow | ANHEDRAL.md ownership notes | anhedral.json source of truth | .env.example inventories. |
|
|
139
|
-
|CODING AGENT Ask name/domain -> resolve modules -> generate -> read docs/manifest -> doctor -> provision -> verify -> |
|
|
140
|
-
|hand off. |
|
|
141
|
-
|SUBAGENTS Lead owns mutations; delegate docs/env inventory, read-only DNS checks, and final verification without secrets. |
|
|
142
|
-
|COMPUTER USE Drive provider consoles after user authentication; configure accounts, domains, OAuth, DNS, stores, and |
|
|
143
|
-
|rollout. |
|
|
144
|
-
|SECRET HANDOFF Stop before Generate/Reveal/Create; name the variable/file; user pastes directly into uncommitted |
|
|
145
|
-
|env/provider UI. |
|
|
146
|
-
|UI DX Source-owned components, target routing, accessibility, ordinary framework APIs, and no hidden proprietary runtime. |
|
|
147
|
-
|OPERATIONS DX Exact root commands, selection-aware docs/scripts, machine-readable plans, provider ledger, and explicit |
|
|
148
|
-
|stop gates. |
|
|
149
|
-
+==========================================================================================================================+
|
|
150
|
-
|
|
|
151
|
-
v
|
|
152
|
-
+==========================================================================================================================+
|
|
153
|
-
| 8 VERIFY, RELEASE + OPERATE |
|
|
154
|
-
+--------------------------------------------------------------------------------------------------------------------------+
|
|
155
|
-
|LOCAL Smallest package check -> typecheck -> full verify -> build -> doctor; never weaken a failing gate. |
|
|
156
|
-
|DATABASE Generate -> review/commit SQL -> drift gate -> controlled migrate -> health/readiness checks. |
|
|
157
|
-
|RUNTIME API coverage, auth/CORS, billing replay/order, Ably reconnect, R2 upload/read/range/cache, Worker method/host |
|
|
158
|
-
|security. |
|
|
159
|
-
|CLIENTS Next build | Expo compatibility/device checks | packaged Electron smoke/upgrade | live WXT MV3 worker in Chrome. |
|
|
160
|
-
|INFRA Confirm provider team/resource names, protected env presence, DNS answers, TLS, Vercel health, Worker bindings, and |
|
|
161
|
-
|logs. |
|
|
162
|
-
|CI Pinned toolchain, strict pnpm policy, allowed build scripts, OSV audit, secret scan, deterministic outputs, and |
|
|
163
|
-
|release checks. |
|
|
164
|
-
|RELEASES Vercel preview/prod | TestFlight/Play tracks | browser-store trusted/review | signed desktop staged update |
|
|
165
|
-
|channel. |
|
|
166
|
-
|RECOVERY Transaction rollback, provider backups, database rollback plan, staged/phased rollout, telemetry, and documented |
|
|
167
|
-
|owners. |
|
|
168
|
-
+==========================================================================================================================+
|
|
169
|
-
```
|
|
170
|
-
|
|
171
|
-
## Runtime connection summary
|
|
172
|
-
|
|
173
|
-
```text
|
|
174
|
-
web / mobile / desktop / extension
|
|
175
|
-
|
|
|
176
|
-
v
|
|
177
|
-
packages/api-client
|
|
178
|
-
|
|
|
179
|
-
v
|
|
180
|
-
Fastify API + Zod contracts
|
|
181
|
-
| | |
|
|
182
|
-
v v v
|
|
183
|
-
Clerk identity Neon private R2
|
|
184
|
-
|
|
|
185
|
-
v
|
|
186
|
-
RevenueCat entitlement
|
|
187
|
-
|
|
|
188
|
-
v
|
|
189
|
-
Ably event
|
|
190
|
-
|
|
|
191
|
-
v
|
|
192
|
-
clients refetch state
|
|
193
|
-
|
|
194
|
-
signed desktop release -> private update R2 -> updates.<domain> Worker -> electron-updater
|
|
195
|
-
```
|
|
196
|
-
|
|
197
|
-
The runtime summary is intentionally smaller than the lifecycle map. It shows
|
|
198
|
-
only application data flow; DNS, provisioning, release gates, and agent actions
|
|
199
|
-
remain in the master map above.
|