anhedral 0.3.0 → 0.4.0
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/CHANGELOG.md +22 -0
- package/CONTRIBUTING.md +4 -1
- package/LICENSE +201 -26
- package/README.md +71 -13
- package/SECURITY.md +4 -2
- package/SKILL.md +78 -11
- package/dist/architecture/contributions.js +7 -0
- package/dist/architecture/modules.d.ts +2 -2
- package/dist/architecture/modules.js +11 -3
- package/dist/bin.js +17 -5
- package/dist/cli.d.ts +2 -2
- package/dist/cli.js +4 -1
- package/dist/composers/root.js +1 -0
- package/dist/dependencies.d.ts +2 -0
- package/dist/dependencies.js +8 -1
- package/dist/index.d.ts +2 -2
- package/dist/index.js +1 -1
- package/dist/prompts.d.ts +1 -1
- package/dist/scaffold.d.ts +8 -0
- package/dist/scaffold.js +306 -38
- package/dist/templates/api.js +8 -0
- package/dist/templates/desktop.js +78 -11
- package/dist/templates/electron-updater.d.ts +3 -0
- package/dist/templates/electron-updater.js +358 -0
- package/dist/templates/shared.js +23 -6
- package/dist/version.d.ts +1 -1
- package/dist/version.js +1 -1
- package/docs/conventions.md +4 -1
- package/docs/master-stack-map.md +192 -0
- package/docs/output-tree-contract.md +45 -5
- package/{references → docs/references}/manual-scaffolding.md +24 -7
- package/docs/references/provisioning.md +220 -0
- package/package.json +5 -4
package/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,28 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
|
|
|
6
6
|
|
|
7
7
|
## Unreleased
|
|
8
8
|
|
|
9
|
+
## 0.4.0 - 2026-07-22
|
|
10
|
+
|
|
11
|
+
### Added
|
|
12
|
+
|
|
13
|
+
- Add the `electron-updater` feature module, including packaged-app update checks, private R2 storage, a read-only bound Cloudflare Worker on a custom domain, ordered architecture-specific publishing commands, and a complete generated release runbook.
|
|
14
|
+
- Make the `anhedral-init` coding-agent skill the recommended setup path, with project/domain intake, Computer Use and subagent orchestration, provider provisioning order, authentication and secret-generation stops, and verified Cloudflare/Vercel domain handoffs.
|
|
15
|
+
- Add the canonical fixed-width master stack map to the published documentation and route the coding-agent skill through it for whole-platform planning and explanation.
|
|
16
|
+
- Add a transactional project-upgrade path so compatible 0.3 projects can adopt 0.4 without regeneration.
|
|
17
|
+
- Add a focused default development loop for the primary web and API surfaces, with `dev:all` available for intentionally launching every selected client.
|
|
18
|
+
|
|
19
|
+
### Changed
|
|
20
|
+
|
|
21
|
+
- Make generated onboarding follow the real environment, managed-Neon, verification, and framework source layout instead of promising an unconfigured one-command boot.
|
|
22
|
+
- Treat developer extension points as user-owned source while retaining conflict protection for generated wiring and mergeable workspace configuration.
|
|
23
|
+
- Publish the skill's provisioning references from their canonical `docs/references` location and validate every packed local documentation link.
|
|
24
|
+
- Upgrade GitHub artifact transfer actions to their Node.js 24-native releases and keep manual npm publication routed through the trusted-publisher workflow identity.
|
|
25
|
+
|
|
26
|
+
### Fixed
|
|
27
|
+
|
|
28
|
+
- Canonicalize module ordering when an incremental feature contributes a previously absent dependency.
|
|
29
|
+
- Attach release integrity metadata beside the npm tarball in GitHub Releases.
|
|
30
|
+
|
|
9
31
|
## 0.3.0 - 2026-07-21
|
|
10
32
|
|
|
11
33
|
### Added
|
package/CONTRIBUTING.md
CHANGED
|
@@ -67,4 +67,7 @@ Scheduled Toolchain Drift failures and release-workflow failures must alert the
|
|
|
67
67
|
|
|
68
68
|
Do not run `npm publish` from a development checkout. Version changes are reviewed before release, and CI publishes the verified tarball. See [docs/RELEASING.md](docs/RELEASING.md).
|
|
69
69
|
|
|
70
|
-
This repository and package are
|
|
70
|
+
This repository and package are licensed under the Apache License 2.0. Unless
|
|
71
|
+
explicitly stated otherwise, contributions intentionally submitted for
|
|
72
|
+
inclusion in Anhedral are provided under the same license, as described in
|
|
73
|
+
Section 5 of [LICENSE](LICENSE).
|
package/LICENSE
CHANGED
|
@@ -1,26 +1,201 @@
|
|
|
1
|
-
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
or
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
10
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
11
|
+
|
|
12
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
13
|
+
the copyright owner that is granting the License.
|
|
14
|
+
|
|
15
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
16
|
+
other entities that control, are controlled by, or are under common
|
|
17
|
+
control with that entity. For the purposes of this definition,
|
|
18
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
19
|
+
direction or management of such entity, whether by contract or
|
|
20
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
21
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
22
|
+
|
|
23
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
24
|
+
exercising permissions granted by this License.
|
|
25
|
+
|
|
26
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
27
|
+
including but not limited to software source code, documentation
|
|
28
|
+
source, and configuration files.
|
|
29
|
+
|
|
30
|
+
"Object" form shall mean any form resulting from mechanical
|
|
31
|
+
transformation or translation of a Source form, including but
|
|
32
|
+
not limited to compiled object code, generated documentation,
|
|
33
|
+
and conversions to other media types.
|
|
34
|
+
|
|
35
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
36
|
+
Object form, made available under the License, as indicated by a
|
|
37
|
+
copyright notice that is included in or attached to the work
|
|
38
|
+
(an example is provided in the Appendix below).
|
|
39
|
+
|
|
40
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
41
|
+
form, that is based on (or derived from) the Work and for which the
|
|
42
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
43
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
44
|
+
of this License, Derivative Works shall not include works that remain
|
|
45
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
46
|
+
the Work and Derivative Works thereof.
|
|
47
|
+
|
|
48
|
+
"Contribution" shall mean any work of authorship, including
|
|
49
|
+
the original version of the Work and any modifications or additions
|
|
50
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
51
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
52
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
53
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
54
|
+
means any form of electronic, verbal, or written communication sent
|
|
55
|
+
to the Licensor or its representatives, including but not limited to
|
|
56
|
+
communication on electronic mailing lists, source code control systems,
|
|
57
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
58
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
59
|
+
excluding communication that is conspicuously marked or otherwise
|
|
60
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
61
|
+
|
|
62
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
63
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
64
|
+
subsequently incorporated within the Work.
|
|
65
|
+
|
|
66
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
67
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
68
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
69
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
70
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
71
|
+
Work and such Derivative Works in Source or Object form.
|
|
72
|
+
|
|
73
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
74
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
75
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
76
|
+
(except as stated in this section) patent license to make, have made,
|
|
77
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
78
|
+
where such license applies only to those patent claims licensable
|
|
79
|
+
by such Contributor that are necessarily infringed by their
|
|
80
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
81
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
82
|
+
institute patent litigation against any entity (including a
|
|
83
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
84
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
85
|
+
or contributory patent infringement, then any patent licenses
|
|
86
|
+
granted to You under this License for that Work shall terminate
|
|
87
|
+
as of the date such litigation is filed.
|
|
88
|
+
|
|
89
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
90
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
91
|
+
modifications, and in Source or Object form, provided that You
|
|
92
|
+
meet the following conditions:
|
|
93
|
+
|
|
94
|
+
(a) You must give any other recipients of the Work or
|
|
95
|
+
Derivative Works a copy of this License; and
|
|
96
|
+
|
|
97
|
+
(b) You must cause any modified files to carry prominent notices
|
|
98
|
+
stating that You changed the files; and
|
|
99
|
+
|
|
100
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
101
|
+
that You distribute, all copyright, patent, trademark, and
|
|
102
|
+
attribution notices from the Source form of the Work,
|
|
103
|
+
excluding those notices that do not pertain to any part of
|
|
104
|
+
the Derivative Works; and
|
|
105
|
+
|
|
106
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
107
|
+
distribution, then any Derivative Works that You distribute must
|
|
108
|
+
include a readable copy of the attribution notices contained
|
|
109
|
+
within such NOTICE file, excluding those notices that do not
|
|
110
|
+
pertain to any part of the Derivative Works, in at least one
|
|
111
|
+
of the following places: within a NOTICE text file distributed
|
|
112
|
+
as part of the Derivative Works; within the Source form or
|
|
113
|
+
documentation, if provided along with the Derivative Works; or,
|
|
114
|
+
within a display generated by the Derivative Works, if and
|
|
115
|
+
wherever such third-party notices normally appear. The contents
|
|
116
|
+
of the NOTICE file are for informational purposes only and
|
|
117
|
+
do not modify the License. You may add Your own attribution
|
|
118
|
+
notices within Derivative Works that You distribute, alongside
|
|
119
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
120
|
+
that such additional attribution notices cannot be construed
|
|
121
|
+
as modifying the License.
|
|
122
|
+
|
|
123
|
+
You may add Your own copyright statement to Your modifications and
|
|
124
|
+
may provide additional or different license terms and conditions
|
|
125
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
126
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
127
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
128
|
+
the conditions stated in this License.
|
|
129
|
+
|
|
130
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
131
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
132
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
133
|
+
this License, without any additional terms or conditions.
|
|
134
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
135
|
+
the terms of any separate license agreement you may have executed
|
|
136
|
+
with Licensor regarding such Contributions.
|
|
137
|
+
|
|
138
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
139
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
140
|
+
except as required for reasonable and customary use in describing the
|
|
141
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
142
|
+
|
|
143
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
144
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
145
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
146
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
147
|
+
implied, including, without limitation, any warranties or conditions
|
|
148
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
149
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
150
|
+
appropriateness of using or redistributing the Work and assume any
|
|
151
|
+
risks associated with Your exercise of permissions under this License.
|
|
152
|
+
|
|
153
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
154
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
155
|
+
unless required by applicable law (such as deliberate and grossly
|
|
156
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
157
|
+
liable to You for damages, including any direct, indirect, special,
|
|
158
|
+
incidental, or consequential damages of any character arising as a
|
|
159
|
+
result of this License or out of the use or inability to use the
|
|
160
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
161
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
162
|
+
other commercial damages or losses), even if such Contributor
|
|
163
|
+
has been advised of the possibility of such damages.
|
|
164
|
+
|
|
165
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
166
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
167
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
168
|
+
or other liability obligations and/or rights consistent with this
|
|
169
|
+
License. However, in accepting such obligations, You may act only
|
|
170
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
171
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
172
|
+
defend, and hold each Contributor harmless for any liability
|
|
173
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
174
|
+
of your accepting any such warranty or additional liability.
|
|
175
|
+
|
|
176
|
+
END OF TERMS AND CONDITIONS
|
|
177
|
+
|
|
178
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
179
|
+
|
|
180
|
+
To apply the Apache License to your work, attach the following
|
|
181
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
182
|
+
replaced with your own identifying information. (Don't include
|
|
183
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
184
|
+
comment syntax for the file format. We also recommend that a
|
|
185
|
+
file or class name and description of purpose be included on the
|
|
186
|
+
same "printed page" as the copyright notice for easier
|
|
187
|
+
identification within third-party archives.
|
|
188
|
+
|
|
189
|
+
Copyright 2026 Anhedral, Inc.
|
|
190
|
+
|
|
191
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
192
|
+
you may not use this file except in compliance with the License.
|
|
193
|
+
You may obtain a copy of the License at
|
|
194
|
+
|
|
195
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
196
|
+
|
|
197
|
+
Unless required by applicable law or agreed to in writing, software
|
|
198
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
199
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
200
|
+
See the License for the specific language governing permissions and
|
|
201
|
+
limitations under the License.
|
package/README.md
CHANGED
|
@@ -9,18 +9,49 @@ Anhedral generates a complete, production-oriented TypeScript stack whose source
|
|
|
9
9
|
|
|
10
10
|
Anhedral is not a new programming language and generated applications do not run inside a proprietary application framework. It assembles well-documented tools, connects their difficult integration boundaries, and leaves developers with ordinary Next.js, Expo Router, Fastify, Drizzle, Electron, and WXT projects.
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
Anhedral is open source under the [Apache License 2.0](LICENSE). You may use,
|
|
13
|
+
modify, and distribute it subject to that license, including its notice and
|
|
14
|
+
redistribution requirements. Generated applications remain ordinary project
|
|
15
|
+
source that their developers can customize and license for their products.
|
|
13
16
|
|
|
14
|
-
##
|
|
17
|
+
## Recommended: use the coding-agent skill
|
|
18
|
+
|
|
19
|
+
Install the Anhedral skill for Codex, Claude Code, or another compatible coding
|
|
20
|
+
agent:
|
|
21
|
+
|
|
22
|
+
```sh
|
|
23
|
+
pnpm dlx skills add https://github.com/anhedral/anhedral-init --skill anhedral-init
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
Choose the agent and global or project scope when prompted. Then ask the agent:
|
|
27
|
+
|
|
28
|
+
```text
|
|
29
|
+
Use $anhedral-init to create and provision my application.
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
The skill begins by asking for the project name and whether you already own a
|
|
33
|
+
custom domain. It selects the CLI command with you, detects Computer Use and
|
|
34
|
+
subagent support, generates the project, and walks through the selected cloud
|
|
35
|
+
providers. It pauses for sign-in, MFA, payments, secret generation, and final
|
|
36
|
+
release submissions. Paste secrets directly into the instructed uncommitted
|
|
37
|
+
`.env` file or protected provider field—never into chat.
|
|
38
|
+
|
|
39
|
+
## Create an application directly
|
|
15
40
|
|
|
16
41
|
Create the complete stack:
|
|
17
42
|
|
|
18
43
|
```sh
|
|
19
44
|
pnpm dlx anhedral@latest new my-product
|
|
20
45
|
cd my-product
|
|
21
|
-
pnpm dev
|
|
22
46
|
```
|
|
23
47
|
|
|
48
|
+
The generated `README.md` contains the exact next steps for the selected stack.
|
|
49
|
+
For the complete stack, copy the package-local environment examples, configure
|
|
50
|
+
the selected managed providers—including a Neon `DATABASE_URL`—and create the
|
|
51
|
+
reviewed initial migration before running `pnpm dev`. Anhedral intentionally
|
|
52
|
+
does not generate a local Postgres substitute or pretend that production
|
|
53
|
+
provider credentials already exist.
|
|
54
|
+
|
|
24
55
|
With no module flags, `new` includes every supported application surface and backend capability. Generate a focused stack by naming only what the product needs:
|
|
25
56
|
|
|
26
57
|
```sh
|
|
@@ -45,10 +76,11 @@ my-product/
|
|
|
45
76
|
├── apps/
|
|
46
77
|
│ ├── web/ # Next.js App Router + source-owned shadcn/ui
|
|
47
78
|
│ ├── mobile/ # Expo Router + React Native Reusables
|
|
48
|
-
│ ├── api/ # Fastify routes,
|
|
79
|
+
│ ├── api/ # Fastify routes, backend modules, auth, providers
|
|
49
80
|
│ ├── desktop/ # Electron + React
|
|
50
81
|
│ ├── extension/ # WXT browser extension
|
|
51
|
-
│
|
|
82
|
+
│ ├── assets-private-proxy/ # Cloudflare Worker for private asset delivery
|
|
83
|
+
│ └── desktop-updater-worker/ # private R2 Electron update delivery
|
|
52
84
|
├── packages/
|
|
53
85
|
│ ├── contracts/ # shared Zod network contracts
|
|
54
86
|
│ ├── api-client/ # typed client used by every frontend
|
|
@@ -80,7 +112,7 @@ export default function ProjectsPage() {
|
|
|
80
112
|
```
|
|
81
113
|
|
|
82
114
|
```ts
|
|
83
|
-
// packages/contracts/src/
|
|
115
|
+
// packages/contracts/src/app.ts
|
|
84
116
|
import { z } from 'zod';
|
|
85
117
|
|
|
86
118
|
export const ProjectSchema = z.object({ id: z.string(), name: z.string() });
|
|
@@ -88,13 +120,24 @@ export const ProjectListSchema = z.array(ProjectSchema);
|
|
|
88
120
|
```
|
|
89
121
|
|
|
90
122
|
```ts
|
|
91
|
-
//
|
|
123
|
+
// packages/db/src/app-schema.ts
|
|
124
|
+
import { pgTable, text } from 'drizzle-orm/pg-core';
|
|
125
|
+
|
|
126
|
+
export const projects = pgTable('projects', {
|
|
127
|
+
id: text('id').primaryKey(),
|
|
128
|
+
name: text('name').notNull(),
|
|
129
|
+
});
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
```ts
|
|
133
|
+
// apps/api/src/routes/app.ts
|
|
134
|
+
import type { FastifyPluginAsync } from 'fastify';
|
|
92
135
|
import { db } from '@shared/db';
|
|
93
136
|
import { projects } from '@shared/db/schema';
|
|
94
137
|
|
|
95
|
-
export async
|
|
96
|
-
|
|
97
|
-
}
|
|
138
|
+
export const appRoutes: FastifyPluginAsync = async (app) => {
|
|
139
|
+
app.get('/projects', async () => db.select().from(projects));
|
|
140
|
+
};
|
|
98
141
|
```
|
|
99
142
|
|
|
100
143
|
The convention is a conventional vertical flow, not an Anhedral DSL:
|
|
@@ -105,8 +148,8 @@ contracts -> database/service -> Fastify route -> typed API client -> frontend
|
|
|
105
148
|
|
|
106
149
|
- Write web product code under `apps/web` using Next.js conventions.
|
|
107
150
|
- Write mobile product code under `apps/mobile` using Expo Router conventions.
|
|
108
|
-
-
|
|
109
|
-
- Write tables and queries under `packages/db` using Drizzle conventions.
|
|
151
|
+
- Register product routes in `apps/api/src/routes/app.ts` and add server-only feature modules under `apps/api/src` using Fastify conventions.
|
|
152
|
+
- Write product tables in `packages/db/src/app-schema.ts` and queries under `packages/db` using Drizzle conventions.
|
|
110
153
|
- Share only network contracts and client-safe packages with frontends.
|
|
111
154
|
- Import the underlying framework directly whenever its API is the right tool.
|
|
112
155
|
|
|
@@ -123,6 +166,7 @@ contracts -> database/service -> Fastify route -> typed API client -> frontend
|
|
|
123
166
|
| Storage | private Cloudflare R2 | Signed uploads and controlled asset delivery |
|
|
124
167
|
| Billing/realtime | RevenueCat + Ably | Durable entitlements and client invalidation |
|
|
125
168
|
| Desktop | Electron | Predictable cross-platform TypeScript desktop runtime |
|
|
169
|
+
| Desktop updates | electron-updater + private R2 + Worker | Signed automatic updates through a product-owned custom domain |
|
|
126
170
|
| Extension | WXT | Browser-extension entrypoints, builds, and packaging |
|
|
127
171
|
| Workspace | pnpm + Turborepo | Strict dependencies and dependency-aware tasks |
|
|
128
172
|
|
|
@@ -135,6 +179,7 @@ anhedral new <directory> [modules...] Generate a new readable workspace
|
|
|
135
179
|
anhedral init [modules...] Generate in the current empty directory
|
|
136
180
|
anhedral add <module...> Add connected stack capabilities
|
|
137
181
|
anhedral ui add <component...> Add source-owned UI components
|
|
182
|
+
anhedral upgrade Transactionally upgrade a supported project
|
|
138
183
|
anhedral doctor Check ownership and generator drift
|
|
139
184
|
```
|
|
140
185
|
|
|
@@ -143,8 +188,10 @@ Useful examples:
|
|
|
143
188
|
```sh
|
|
144
189
|
anhedral add storage --dry-run
|
|
145
190
|
anhedral add desktop extension
|
|
191
|
+
anhedral add electron-updater
|
|
146
192
|
anhedral ui add button dialog
|
|
147
193
|
anhedral ui add data-table --target web --dry-run
|
|
194
|
+
anhedral upgrade --dry-run
|
|
148
195
|
anhedral doctor --json
|
|
149
196
|
```
|
|
150
197
|
|
|
@@ -154,6 +201,7 @@ Application lifecycle commands remain visible in the generated root `package.jso
|
|
|
154
201
|
|
|
155
202
|
```sh
|
|
156
203
|
pnpm dev
|
|
204
|
+
pnpm dev:all
|
|
157
205
|
pnpm dev:web
|
|
158
206
|
pnpm dev:api
|
|
159
207
|
pnpm typecheck
|
|
@@ -163,7 +211,11 @@ pnpm db:generate
|
|
|
163
211
|
pnpm db:migrate
|
|
164
212
|
```
|
|
165
213
|
|
|
166
|
-
|
|
214
|
+
`pnpm dev` starts the primary product loop: the first selected client plus the
|
|
215
|
+
API when present, or the API by itself for backend-only projects. In the full
|
|
216
|
+
stack that means web plus API. `pnpm dev:all` appears only when the project has
|
|
217
|
+
additional surfaces and intentionally starts all of them. Only commands
|
|
218
|
+
relevant to selected modules are generated.
|
|
167
219
|
|
|
168
220
|
## Extensibility and ownership
|
|
169
221
|
|
|
@@ -182,6 +234,8 @@ anhedral doctor
|
|
|
182
234
|
anhedral add <module> --dry-run
|
|
183
235
|
```
|
|
184
236
|
|
|
237
|
+
When `doctor` reports that a project was generated by a supported older release, run `anhedral upgrade --dry-run`, inspect the plan, and then run `anhedral upgrade`. Version 0.4 supports transactional upgrades from 0.3 projects while preserving user-owned extension seams. If a 0.3 project changed a file that was generator-managed, the upgrade stops instead of overwriting it. Preserve the change in source control, restore that managed file to its recorded 0.3 content, run the upgrade, and then move the product behavior into the new user-owned `app.ts`, `app-schema.ts`, page, component, or `app-window.ts` seam.
|
|
238
|
+
|
|
185
239
|
## Documentation contract
|
|
186
240
|
|
|
187
241
|
Every generated project teaches both humans and coding agents how to work in it:
|
|
@@ -194,6 +248,9 @@ Every generated project teaches both humans and coding agents how to work in it:
|
|
|
194
248
|
|
|
195
249
|
The generator's exact output contract is documented in [docs/output-tree-contract.md](docs/output-tree-contract.md). Contributor architecture remains available in the [source repository](https://github.com/anhedral/anhedral-init/tree/main/docs/architecture).
|
|
196
250
|
|
|
251
|
+
The complete lifecycle, runtime, cloud, command, and coding-agent topology is in
|
|
252
|
+
the [Anhedral master stack map](docs/master-stack-map.md).
|
|
253
|
+
|
|
197
254
|
## Module dependency rules
|
|
198
255
|
|
|
199
256
|
Anhedral resolves integrations as a deterministic graph:
|
|
@@ -203,6 +260,7 @@ auth -> api + db
|
|
|
203
260
|
billing -> auth
|
|
204
261
|
storage -> auth
|
|
205
262
|
native-subscriptions -> mobile + billing
|
|
263
|
+
electron-updater -> desktop
|
|
206
264
|
```
|
|
207
265
|
|
|
208
266
|
Adding a capability brings the infrastructure it actually requires. Unselected providers do not leave dead source files or environment placeholders behind.
|
package/SECURITY.md
CHANGED
|
@@ -15,7 +15,7 @@ Include the affected version, reproduction steps, impact, and any suggested miti
|
|
|
15
15
|
- Release artifacts are built and tested in a read-only job.
|
|
16
16
|
- The exact tarball uploaded by CI is the artifact submitted to npm.
|
|
17
17
|
- npm integrity is checked before and after publication.
|
|
18
|
-
- npm
|
|
18
|
+
- npm publication uses Trusted Publishing: GitHub exchanges an OIDC identity for a short-lived credential only in the publish step of the protected `npm` environment. No npm write token is stored in GitHub.
|
|
19
19
|
- A Git tag and GitHub release are created only after npm confirms the expected artifact integrity.
|
|
20
20
|
- GitHub Actions are pinned to reviewed commit SHAs, and the release Node.js/npm packer is pinned to an exact version.
|
|
21
21
|
- CI queries OSV for every exact package version in `pnpm-lock.yaml` and every dependency version shipped by the generator; it fails closed if the service remains unavailable after bounded retries or reports a finding.
|
|
@@ -32,4 +32,6 @@ UI component installation is an explicit networked supply-chain operation. Anhed
|
|
|
32
32
|
|
|
33
33
|
If a secret-shaped finding is real, do not merely remove it from the latest commit. Revoke or rotate the credential first, identify every log, artifact, cache, fork, and package version that may contain it, and coordinate history or artifact cleanup with the security responder. Treat false positives by changing the example to an unmistakable placeholder; do not add broad path exclusions.
|
|
34
34
|
|
|
35
|
-
Anhedral is
|
|
35
|
+
Anhedral is licensed under the Apache License 2.0. Security research must still
|
|
36
|
+
comply with applicable law and the systems owner's authorization; the software
|
|
37
|
+
license does not authorize testing infrastructure or accounts you do not own.
|
package/SKILL.md
CHANGED
|
@@ -1,18 +1,22 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: anhedral-init
|
|
3
|
-
description:
|
|
3
|
+
description: Guide a user through creating, provisioning, extending, explaining, or diagnosing a complete Anhedral TypeScript stack. Use for skill-led new/init/add/ui/doctor workflows; Computer Use or subagent-assisted cloud setup; domains, DNS, Vercel, Cloudflare, Neon, Clerk, R2, billing, stores, and Electron updates; development inside a generated workspace; ownership interpretation; manual reproduction; or verification.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Anhedral Init
|
|
7
7
|
|
|
8
8
|
Anhedral is a stack generator, not an application runtime or programming language. Generated projects use ordinary framework source and expose the complete integration code. Do not invent Anhedral-specific models, routes, queries, components, or client hooks when the selected framework already has a documented convention.
|
|
9
9
|
|
|
10
|
+
For every new project or provisioning request, begin by asking for the project
|
|
11
|
+
name and whether the user already owns a custom domain for it. Do not run init
|
|
12
|
+
or create provider resources until those answers establish canonical names.
|
|
13
|
+
|
|
10
14
|
Use Node.js 20.19+ or 22.12+ and pnpm. `new` creates a destination directory; `init` works in an empty current directory where `.git`, `.gitignore`, and `.DS_Store` are allowed.
|
|
11
15
|
|
|
12
16
|
## Choose the construction path
|
|
13
17
|
|
|
14
18
|
- Use the manual path whenever the user asks to avoid the Anhedral CLI, the CLI is unavailable, or the task requires explaining/reproducing the scaffold itself.
|
|
15
|
-
- Before creating or changing files manually, read [references/manual-scaffolding.md](references/manual-scaffolding.md) completely and follow its ordered procedure. Treat it as the canonical manual checklist, including its source-file matrix and feature gates.
|
|
19
|
+
- Before creating or changing files manually, read [docs/references/manual-scaffolding.md](docs/references/manual-scaffolding.md) completely and follow its ordered procedure. Treat it as the canonical manual checklist, including its source-file matrix and feature gates.
|
|
16
20
|
- Use the CLI path only when the user permits it. Do not silently substitute `anhedral init`, `anhedral add`, imported generator code, or a generated demo for the manual path.
|
|
17
21
|
- For an exact-version scaffold inside the Anhedral source repository, render from the current `src/templates/*.ts`, `src/scaffold.ts`, and `src/dependencies.ts`; do not copy stale demo output. Outside that repository, implement the behavior and file contract in the manual reference and pin a mutually compatible toolchain.
|
|
18
22
|
|
|
@@ -22,7 +26,7 @@ The manual path must leave a complete working workspace, not merely a directory
|
|
|
22
26
|
|
|
23
27
|
Choose app surfaces from `web`, `mobile`, `api`, `desktop`, and `extension`.
|
|
24
28
|
|
|
25
|
-
Choose
|
|
29
|
+
Choose features from `db`, `auth`, `billing`, `storage`, `native-subscriptions`, and `electron-updater`.
|
|
26
30
|
|
|
27
31
|
Apply these dependency rules automatically:
|
|
28
32
|
|
|
@@ -31,10 +35,58 @@ auth -> api + db
|
|
|
31
35
|
billing -> auth
|
|
32
36
|
storage -> auth
|
|
33
37
|
native-subscriptions -> mobile + billing
|
|
38
|
+
electron-updater -> desktop
|
|
34
39
|
```
|
|
35
40
|
|
|
36
41
|
With no module flags, generate the full stack.
|
|
37
42
|
|
|
43
|
+
## Master stack map
|
|
44
|
+
|
|
45
|
+
Read [docs/master-stack-map.md](docs/master-stack-map.md) completely before
|
|
46
|
+
explaining the whole platform, selecting modules for a complete product, or
|
|
47
|
+
planning cross-provider provisioning. Treat it as the canonical map of the
|
|
48
|
+
stack, command surface, runtime connections, agent workflow, and release path.
|
|
49
|
+
|
|
50
|
+
```text
|
|
51
|
+
project + domain intake
|
|
52
|
+
|
|
|
53
|
+
v
|
|
54
|
+
1 select + plan -> 2 generate safely -> 3 one pnpm/Turborepo workspace
|
|
55
|
+
|
|
|
56
|
+
v
|
|
57
|
+
4 connected product capabilities -> 5 provision cloud + DNS
|
|
58
|
+
|
|
|
59
|
+
v
|
|
60
|
+
6 generated package.json commands -> 7 developer/agent/Computer Use
|
|
61
|
+
|
|
|
62
|
+
v
|
|
63
|
+
8 verify, release, and operate
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
Use the full fixed-width ASCII map from the document when the user asks for the
|
|
67
|
+
master stack map. Do not redraw it from memory or omit unselected modules when
|
|
68
|
+
describing Anhedral's complete capability surface; mark modules as selected or
|
|
69
|
+
unselected separately.
|
|
70
|
+
|
|
71
|
+
## Run the guided init workflow
|
|
72
|
+
|
|
73
|
+
Read [docs/references/provisioning.md](docs/references/provisioning.md) completely before
|
|
74
|
+
starting a new project or provisioning any provider. Follow its intake,
|
|
75
|
+
capability discovery, Computer Use, subagent, authentication, secret-handling,
|
|
76
|
+
domain, provider-order, and verification gates.
|
|
77
|
+
|
|
78
|
+
The lead agent must:
|
|
79
|
+
|
|
80
|
+
1. Ask for project name and existing/custom-domain status first.
|
|
81
|
+
2. Discover whether Computer Use/browser control and subagents are available.
|
|
82
|
+
3. Resolve modules and show the user canonical project/resource names.
|
|
83
|
+
4. Run the explicit CLI command, then read the generated `PRODUCTION.md`.
|
|
84
|
+
5. Provision only selected providers, pausing for sign-in, MFA, secret
|
|
85
|
+
generation, purchases, and final submissions exactly as the reference says.
|
|
86
|
+
6. Keep secrets out of chat and tool output; have the user paste them directly
|
|
87
|
+
into uncommitted environment files and protected provider fields.
|
|
88
|
+
7. Verify code, cloud resources, DNS, TLS, and provider health before handoff.
|
|
89
|
+
|
|
38
90
|
## Initialize
|
|
39
91
|
|
|
40
92
|
```sh
|
|
@@ -74,23 +126,27 @@ Use the native source conventions:
|
|
|
74
126
|
|
|
75
127
|
- Next.js code belongs in `apps/web/app`, `apps/web/components`, and `apps/web/lib`.
|
|
76
128
|
- Expo Router code belongs in `apps/mobile/app` and `apps/mobile/components`.
|
|
77
|
-
- Fastify
|
|
78
|
-
-
|
|
79
|
-
-
|
|
80
|
-
- Drizzle
|
|
129
|
+
- Product Fastify route registration belongs in `apps/api/src/routes/app.ts`. Server-only feature modules live alongside the managed integrations in `apps/api/src`.
|
|
130
|
+
- Product Zod network schemas belong in `packages/contracts/src/app.ts`.
|
|
131
|
+
- Product client-safe HTTP methods belong in `packages/api-client/src/app.ts`.
|
|
132
|
+
- Product Drizzle tables belong in `packages/db/src/app-schema.ts`; generate and review SQL migrations.
|
|
81
133
|
|
|
82
134
|
Implement an end-to-end feature as `contracts -> database/service -> route -> API client -> frontend`. Frontends may import contracts and client-safe packages, never API services, database connections, or server environments. This stack uses managed Neon and intentionally has no local Postgres service.
|
|
83
135
|
|
|
84
136
|
## Add modules safely
|
|
85
137
|
|
|
86
|
-
Run `add` only from a project containing `anhedral.json` schema v5:
|
|
138
|
+
Run `add` only from a project containing `anhedral.json` schema v5 at the current generator version. If `doctor` identifies a supported older generator, preview and apply its transactional upgrade first:
|
|
87
139
|
|
|
88
140
|
```sh
|
|
141
|
+
pnpm dlx anhedral@latest upgrade --dry-run
|
|
142
|
+
pnpm dlx anhedral@latest upgrade
|
|
89
143
|
pnpm dlx anhedral@latest add desktop extension
|
|
90
144
|
pnpm dlx anhedral@latest add storage --dry-run
|
|
91
145
|
```
|
|
92
146
|
|
|
93
|
-
Use `--dry-run` before a consequential add. Use `--json` when another program needs the plan; JSON failures include a stable `code` and a human-readable `error`. Use `--verbose` for interactive child-command diagnostics.
|
|
147
|
+
Use `--dry-run` before a consequential add. Use `--json` when another program needs the plan; JSON failures include a stable `code` and a human-readable `error`. Use `--verbose` for interactive child-command diagnostics. Anhedral preserves recorded user-owned extension files and intentionally refuses modified managed files, symlinks, and unowned collisions; do not bypass those conflicts.
|
|
148
|
+
|
|
149
|
+
For a 0.3 upgrade blocked by a modified managed file, preserve the change in source control, restore that file to its recorded 0.3 content, apply the upgrade, and port the product behavior into the corresponding 0.4 user-owned extension seam. Never approve the upgrade by rewriting manifest hashes.
|
|
94
150
|
|
|
95
151
|
Require the manifest generator version to match the running CLI. Regenerate projects created by another version; do not add compatibility branches.
|
|
96
152
|
|
|
@@ -145,10 +201,16 @@ Common selected keys are:
|
|
|
145
201
|
- Ably billing synchronization: server-only `ABLY_API_KEY`; clients obtain scoped tokens from the API
|
|
146
202
|
- R2: `BASE_URL`, `R2_ACCOUNT_ID`, `R2_ACCESS_KEY_ID`, `R2_SECRET_ACCESS_KEY`, `R2_BUCKET_NAME`, `R2_PREFIX=storage`, `R2_PROXY_READ_URL_TTL_SECONDS=600`; keep `CLOUDFLARE_API_TOKEN` operations/CI-only
|
|
147
203
|
- Internal billing/storage jobs: high-entropy server-only `CRON_SECRET`
|
|
204
|
+
- Electron updates: `DESKTOP_UPDATE_BASE_URL` in `apps/desktop/electron-builder.env`; the private R2 binding needs no credential in the packaged application
|
|
148
205
|
|
|
149
206
|
Never commit real `.env` files. Keep `ANHEDRAL_DEMO=false` in production.
|
|
150
207
|
|
|
151
|
-
Run only scripts present for installed modules.
|
|
208
|
+
Run only scripts present for installed modules. `pnpm dev` starts the primary
|
|
209
|
+
product loop—web plus API when web is selected, otherwise the first selected
|
|
210
|
+
surface. A multi-surface project also exposes `pnpm dev:all`; use it only when
|
|
211
|
+
the user wants every selected development server. Typical focused commands
|
|
212
|
+
include `dev:web`, `dev:mobile`, `dev:api`, `dev:desktop`, `dev:extension`,
|
|
213
|
+
corresponding `verify:*` scripts, and database scripts for `db` projects.
|
|
152
214
|
|
|
153
215
|
## Understand deployment
|
|
154
216
|
|
|
@@ -158,6 +220,11 @@ For billing, keep Neon authoritative: RevenueCat reconciliation writes the subsc
|
|
|
158
220
|
|
|
159
221
|
Use `apps/mobile` for EAS, `pnpm desktop:build` for a current-host Electron artifact, matching platform-specific desktop scripts in CI, and `pnpm extension:zip` for the WXT archive.
|
|
160
222
|
|
|
223
|
+
For `electron-updater`, provision the generated private R2 bucket and
|
|
224
|
+
`desktop-updater` Worker at `updates.<domain>`. Keep the Worker custom domain and
|
|
225
|
+
`DESKTOP_UPDATE_BASE_URL` identical. Build signed artifacts on each native
|
|
226
|
+
platform and publish artifacts before mutable channel metadata.
|
|
227
|
+
|
|
161
228
|
For storage, generate `apps/assets-private-proxy` plus `cloudflare/r2-cors.template.json` and keep the R2 bucket private. The Worker must be named `assets-private-proxy`, bind the normalized `<project>-assets` bucket as `ASSETS`, disable `workers.dev`, and own `assets.<domain>` as a Worker Custom Domain. Presigned uploads continue on the R2 S3 API hostname. Root every key below `R2_PREFIX=storage`; expose only `storage/confirmed/` through the Worker and reject staging plus `generation-inputs`. Authenticated private reads must verify upload ownership and return a presigned GET URL bounded by `R2_PROXY_READ_URL_TTL_SECONDS`.
|
|
162
229
|
|
|
163
230
|
When explaining domains, distinguish DNS delegation from registrar transfer. A GoDaddy registration can use Cloudflare authoritative nameservers immediately; transferring registration/billing to Cloudflare Registrar is optional and subject to eligibility locks. Keep Vercel app/API A or CNAME records DNS-only in Cloudflare, while Worker Custom Domains stay Cloudflare-managed and proxied.
|
|
@@ -174,4 +241,4 @@ pnpm build
|
|
|
174
241
|
|
|
175
242
|
Use `pnpm --filter ./apps/api test` when the API exists. If verification fails, report the exact package and command rather than replacing generated ownership records manually.
|
|
176
243
|
|
|
177
|
-
For exact representative trees, consult `docs/output-tree-contract.md` in the Anhedral repository. During manual construction, also compare the finished workspace with the file matrix in [references/manual-scaffolding.md](references/manual-scaffolding.md); every selected conditional file must exist and every unselected provider integration must be absent.
|
|
244
|
+
For exact representative trees, consult `docs/output-tree-contract.md` in the Anhedral repository. During manual construction, also compare the finished workspace with the file matrix in [docs/references/manual-scaffolding.md](docs/references/manual-scaffolding.md); every selected conditional file must exist and every unselected provider integration must be absent.
|