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.
Files changed (89) hide show
  1. package/README.md +35 -265
  2. package/assets/anhedral-cli-init-technical.svg +322 -0
  3. package/assets/anhedral-cli-init.svg +257 -173
  4. package/dist/bin.js +28 -191
  5. package/dist/dependencies.d.ts +7 -57
  6. package/dist/dependencies.js +96 -308
  7. package/dist/index.d.ts +2 -7
  8. package/dist/index.js +1 -4
  9. package/dist/platforms/desktop.js +401 -0
  10. package/dist/platforms/extension.js +401 -0
  11. package/dist/platforms/mobile.js +232 -0
  12. package/dist/project.d.ts +0 -26
  13. package/dist/standard-products.d.ts +2 -0
  14. package/dist/standard-products.js +6 -0
  15. package/dist/standard.d.ts +18 -0
  16. package/dist/standard.js +595 -0
  17. package/dist/version.d.ts +1 -1
  18. package/dist/version.js +1 -1
  19. package/docs/application-stack-standard.md +700 -0
  20. package/package.json +29 -51
  21. package/CHANGELOG.md +0 -178
  22. package/CONTRIBUTING.md +0 -77
  23. package/SECURITY.md +0 -37
  24. package/SKILL.md +0 -339
  25. package/assets/images/svg/ably-symbol-color.svg +0 -8
  26. package/bin/anhedral.js +0 -2
  27. package/dist/architecture/contributions.d.ts +0 -28
  28. package/dist/architecture/contributions.js +0 -125
  29. package/dist/architecture/index.d.ts +0 -12
  30. package/dist/architecture/index.js +0 -6
  31. package/dist/architecture/manifest.d.ts +0 -53
  32. package/dist/architecture/manifest.js +0 -283
  33. package/dist/architecture/modules.d.ts +0 -41
  34. package/dist/architecture/modules.js +0 -187
  35. package/dist/architecture/plan.d.ts +0 -58
  36. package/dist/architecture/plan.js +0 -145
  37. package/dist/architecture/templates.d.ts +0 -10
  38. package/dist/architecture/templates.js +0 -23
  39. package/dist/cli.d.ts +0 -32
  40. package/dist/cli.js +0 -281
  41. package/dist/composers/root.d.ts +0 -6
  42. package/dist/composers/root.js +0 -35
  43. package/dist/print.d.ts +0 -8
  44. package/dist/print.js +0 -48
  45. package/dist/prompts.d.ts +0 -6
  46. package/dist/prompts.js +0 -41
  47. package/dist/scaffold.d.ts +0 -64
  48. package/dist/scaffold.js +0 -2102
  49. package/dist/template-source.d.ts +0 -20
  50. package/dist/template-source.js +0 -180
  51. package/dist/templates/api.d.ts +0 -2
  52. package/dist/templates/api.js +0 -3187
  53. package/dist/templates/assets-private-proxy.d.ts +0 -3
  54. package/dist/templates/assets-private-proxy.js +0 -277
  55. package/dist/templates/desktop.js +0 -792
  56. package/dist/templates/electron-updater.d.ts +0 -3
  57. package/dist/templates/electron-updater.js +0 -358
  58. package/dist/templates/extension.js +0 -856
  59. package/dist/templates/first-run.d.ts +0 -2
  60. package/dist/templates/first-run.js +0 -167
  61. package/dist/templates/mobile.js +0 -861
  62. package/dist/templates/shared.d.ts +0 -2
  63. package/dist/templates/shared.js +0 -577
  64. package/dist/templates/web.d.ts +0 -2
  65. package/dist/templates/web.js +0 -569
  66. package/dist/toolchain.d.ts +0 -3
  67. package/dist/toolchain.js +0 -8
  68. package/dist/ui.d.ts +0 -33
  69. package/dist/ui.js +0 -199
  70. package/dist/workspace-config.d.ts +0 -11
  71. package/dist/workspace-config.js +0 -372
  72. package/docs/NORTHSTAR.md +0 -114
  73. package/docs/conventions.md +0 -94
  74. package/docs/engineering-principles.md +0 -88
  75. package/docs/master-stack-map.md +0 -199
  76. package/docs/output-tree-contract.md +0 -493
  77. package/docs/references/manual-scaffolding.md +0 -421
  78. package/docs/references/provisioning.md +0 -577
  79. package/scripts/render-master-stack-map.mjs +0 -510
  80. package/templates/api-fastify/apps/api/tsconfig.json +0 -20
  81. package/templates/catalog.json +0 -23
  82. package/templates/db-drizzle/packages/db/tsconfig.json +0 -14
  83. package/templates/desktop-electron/apps/desktop/tsconfig.json +0 -37
  84. package/templates/extension-wxt/apps/extension/tsconfig.json +0 -41
  85. package/templates/mobile-expo/apps/mobile/expo-env.d.ts +0 -1
  86. package/templates/web-next/apps/web/next-env.d.ts +0 -6
  87. /package/dist/{templates → platforms}/desktop.d.ts +0 -0
  88. /package/dist/{templates → platforms}/extension.d.ts +0 -0
  89. /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.
@@ -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.
@@ -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
- ![Anhedral master stack diagram](../assets/anhedral-cli-init.svg)
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.