@phreshos/cli 0.1.42 → 0.1.44
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 +67 -414
- package/dist/template/README.md +50 -9
- package/dist/template/client/app.tsx +1 -1
- package/dist/template/package.json +10 -10
- package/dist/template/phresh.config.ts +1 -1
- package/dist/template.json +2 -2
- package/package.json +3 -3
package/README.md
CHANGED
|
@@ -1,448 +1,101 @@
|
|
|
1
|
-
#
|
|
1
|
+
# `@phreshos/cli`
|
|
2
2
|
|
|
3
|
-
The `phresh` command for creating and operating Programs
|
|
4
|
-
|
|
3
|
+
The `phresh` command for creating and operating Programs and managing the
|
|
4
|
+
PhreshOS System on the current machine.
|
|
5
5
|
|
|
6
|
-
|
|
6
|
+
The CLI uses the same public System interface as the Node and Server SDKs. It
|
|
7
|
+
adds command parsing, terminal presentation, project workflows, packaging, and
|
|
8
|
+
native service management.
|
|
7
9
|
|
|
8
|
-
|
|
9
|
-
active testing. The architecture's components will be released in stages as
|
|
10
|
-
their contracts and integrations are verified.
|
|
10
|
+
## Installation
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
12
|
+
| Package manager | Command |
|
|
13
|
+
| --- | --- |
|
|
14
|
+
| npm | `npm install --global @phreshos/cli` |
|
|
15
|
+
| pnpm | `pnpm add --global @phreshos/cli` |
|
|
16
|
+
| Bun | `bun add --global @phreshos/cli` |
|
|
17
|
+
| Yarn Classic | `yarn global add @phreshos/cli` |
|
|
16
18
|
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
phresh pack # run the optional build, then package its result
|
|
21
|
-
phresh install # lay this program out on this machine
|
|
22
|
-
phresh uninstall # remove its installed form
|
|
23
|
-
phresh start # run what your build left, and stay with it
|
|
24
|
-
phresh dev # run from source, and stay with it
|
|
25
|
-
phresh system status # inspect the local System and its background service
|
|
26
|
-
phresh program list # inspect authoritative state in the running System
|
|
27
|
-
phresh describe endpoint ask # read one capability's exact contract
|
|
28
|
-
```
|
|
19
|
+
Node.js 20.10 or newer is required.
|
|
20
|
+
|
|
21
|
+
## Program projects
|
|
29
22
|
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
23
|
+
```sh
|
|
24
|
+
phresh create
|
|
25
|
+
phresh init
|
|
26
|
+
phresh dev
|
|
27
|
+
phresh start
|
|
28
|
+
phresh install
|
|
29
|
+
phresh uninstall
|
|
30
|
+
phresh pack
|
|
31
|
+
```
|
|
35
32
|
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
namespaces. System execution and native lifecycle remain isolated under
|
|
40
|
-
`phresh system`.
|
|
33
|
+
`create` produces the official starter Program. The remaining commands operate
|
|
34
|
+
on the current Program project, derive its concrete definition, and delegate
|
|
35
|
+
runtime operations to the connected System.
|
|
41
36
|
|
|
42
|
-
## System
|
|
37
|
+
## System
|
|
43
38
|
|
|
44
|
-
```
|
|
39
|
+
```sh
|
|
45
40
|
phresh system install
|
|
46
|
-
phresh system uninstall
|
|
47
41
|
phresh system status
|
|
48
|
-
phresh system version
|
|
49
42
|
phresh system start
|
|
50
43
|
phresh system stop
|
|
51
44
|
phresh system enable
|
|
52
45
|
phresh system disable
|
|
46
|
+
phresh system uninstall
|
|
53
47
|
```
|
|
54
48
|
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
installs production dependencies into a staged version directory, atomically
|
|
59
|
-
points the stable `current` path at it, then registers, enables, and starts the
|
|
60
|
-
native per-user service. The selected release and the service entry therefore
|
|
61
|
-
cannot become two competing sources of truth if installation is interrupted.
|
|
62
|
-
It never reads a source checkout and never requires Bun or TypeScript.
|
|
63
|
-
|
|
64
|
-
The System runs under `launchd` on macOS, a real `systemd --user` manager on
|
|
65
|
-
Linux, and a least-privilege per-user scheduled task on Windows. In Linux
|
|
66
|
-
containers with no init manager, it runs as a detached user-owned background
|
|
67
|
-
process that survives the terminal but ends with the container. Automatic
|
|
68
|
-
startup is unavailable there rather than being reported as enabled. `start`
|
|
69
|
-
and `stop` change current execution only; where a native manager exists,
|
|
70
|
-
`enable` and `disable` change automatic startup only. Successful installation
|
|
71
|
-
and startup show the desktop address. `status` reports that same address with
|
|
72
|
-
the installed version, service readiness, and automatic startup without
|
|
73
|
-
changing them; `version` reports only the installed System release.
|
|
74
|
-
|
|
75
|
-
Installation files and persistent System state have separate homes. Removing
|
|
76
|
-
the System unregisters its service and removes its release files while keeping
|
|
77
|
-
`~/.phreshos`, including Programs and owner data. The owner-local gateway uses an
|
|
78
|
-
owner-only socket file on POSIX and an owner-created duplex named pipe on
|
|
79
|
-
Windows; neither becomes a network endpoint or introduces a bearer secret.
|
|
80
|
-
|
|
81
|
-
## create
|
|
82
|
-
|
|
83
|
-
`phresh create <directory>` creates a complete Server and Client Program from
|
|
84
|
-
the maintained `PhreshOS/phresh-program` repository. The CLI build downloads
|
|
85
|
-
the newest complete stable release, validates its source identity and version,
|
|
86
|
-
removes repository-only material, and bundles that exact authoring project.
|
|
87
|
-
The resolved source digest is recorded with the bundle. The installed CLI
|
|
88
|
-
therefore creates projects offline without reading a live branch or maintaining
|
|
89
|
-
a release pin or second template by hand.
|
|
90
|
-
|
|
91
|
-
The directory name becomes the stable kebab-case Program identity. In a
|
|
92
|
-
terminal, `create` asks for the directory when it is omitted, the readable
|
|
93
|
-
Program name, and the package manager. With no terminal, the directory is the
|
|
94
|
-
first argument and every optional choice is named:
|
|
95
|
-
|
|
96
|
-
```bash
|
|
97
|
-
phresh create status-board \
|
|
98
|
-
--name "Status Board" \
|
|
99
|
-
--package-manager npm
|
|
100
|
-
```
|
|
101
|
-
|
|
102
|
-
Dependencies are installed by default. `--no-install` creates the same valid
|
|
103
|
-
project and leaves installation as the first reported next step. Generated and
|
|
104
|
-
initialized Programs always use the published package ranges embedded in the
|
|
105
|
-
CLI; repository layout never changes dependency meaning.
|
|
106
|
-
|
|
107
|
-
## Saying something to a program you start
|
|
108
|
-
|
|
109
|
-
```bash
|
|
110
|
-
phresh dev --run-option-path=/notes.md --run-option-line=42
|
|
111
|
-
```
|
|
112
|
-
|
|
113
|
-
Read back by name, on either half:
|
|
114
|
-
|
|
115
|
-
```ts
|
|
116
|
-
const path = await context.option("path")
|
|
117
|
-
```
|
|
118
|
-
|
|
119
|
-
**Options are text, all of them.** An option must mean the same thing
|
|
120
|
-
however the process was started, and a command line can only hand over
|
|
121
|
-
text — a number made here would be a guess about your program's meaning
|
|
122
|
-
by the one party with no way to know it. Is `--run-option-id=007` seven,
|
|
123
|
-
or a string with two noughts in front? Only your program knows, so your
|
|
124
|
-
program decides: `Number(...)`, once, where the meaning is.
|
|
125
|
-
|
|
126
|
-
Which is what argv and the environment have always been, for the same
|
|
127
|
-
reason. The prefix is long because these share a line with the tool's
|
|
128
|
-
own flags, and a program wanting an option called `client` should not
|
|
129
|
-
have to fight the CLI for the word.
|
|
130
|
-
|
|
131
|
-
## phresh.config is not a program's configuration
|
|
132
|
-
|
|
133
|
-
A program's configuration is **derived** from it — three times, and the
|
|
134
|
-
derivations differ only in where each half is said to be. That is the
|
|
135
|
-
rule everything else here follows from.
|
|
136
|
-
|
|
137
|
-
It follows that every field which lands in a `program.json` is spelled
|
|
138
|
-
the way the contract spells it and crosses untouched: `size`, not a
|
|
139
|
-
width and a height; `startCommand` or `entryFile`, not a generic command.
|
|
140
|
-
|
|
141
|
-
An optional top-level `buildCommand` is authoring metadata. `phresh start`,
|
|
142
|
-
`phresh install`, and `phresh pack` run it from this project before consuming
|
|
143
|
-
the production files. It never crosses into `program.json` or the system.
|
|
144
|
-
`phresh dev` uses the development declarations and does not build.
|
|
145
|
-
|
|
146
|
-
Everything else is yours: where each half is left.
|
|
147
|
-
|
|
148
|
-
```ts
|
|
149
|
-
import { defineConfig } from "@phreshos/core"
|
|
150
|
-
|
|
151
|
-
export default defineConfig({
|
|
152
|
-
|
|
153
|
-
identity: "file-manager", // kebab-case: the program's stable address
|
|
154
|
-
|
|
155
|
-
name: "File Manager", // what a person reads
|
|
156
|
-
|
|
157
|
-
version: "0.1.0",
|
|
158
|
-
|
|
159
|
-
description: "A file manager",
|
|
160
|
-
|
|
161
|
-
icon: "icon.png",
|
|
162
|
-
|
|
163
|
-
categories: ["Utilities"],
|
|
164
|
-
|
|
165
|
-
keywords: ["files", "storage"],
|
|
166
|
-
|
|
167
|
-
website: "https://example.com/file-manager",
|
|
168
|
-
|
|
169
|
-
buildCommand: "bun run build",
|
|
170
|
-
|
|
171
|
-
server: {
|
|
172
|
-
|
|
173
|
-
location: "build/server",
|
|
174
|
-
|
|
175
|
-
installCommand: "npm ci",
|
|
176
|
-
|
|
177
|
-
uninstallCommand: "npm run clean:external",
|
|
178
|
-
|
|
179
|
-
startCommand: "node main.js",
|
|
180
|
-
|
|
181
|
-
development: {
|
|
182
|
-
|
|
183
|
-
startCommand: "tsx server/main.ts"
|
|
184
|
-
}
|
|
185
|
-
},
|
|
186
|
-
|
|
187
|
-
client: {
|
|
188
|
-
|
|
189
|
-
location: "dist",
|
|
190
|
-
|
|
191
|
-
size: { width: "1/2", height: 440 },
|
|
192
|
-
|
|
193
|
-
position: { x: 60, y: 40 },
|
|
194
|
-
|
|
195
|
-
development: {
|
|
196
|
-
|
|
197
|
-
url: "http://localhost:5173",
|
|
198
|
-
|
|
199
|
-
startCommand: "bun run dev"
|
|
200
|
-
}
|
|
201
|
-
}
|
|
202
|
-
})
|
|
203
|
-
```
|
|
204
|
-
|
|
205
|
-
**`identity` identifies; `name` is read.** The identity is kebab-case
|
|
206
|
-
because it is also the directory the system lays your program out in, so
|
|
207
|
-
it is a path component before anything else. The name is free-form,
|
|
208
|
-
identifies nothing, and absent means the identity serves for both.
|
|
209
|
-
|
|
210
|
-
`identity`, `version` and `description` begin from your `package.json`
|
|
211
|
-
during `init`; the readable `name` is asked for. They are written into
|
|
212
|
-
the config rather than read from the manifest later. `pack` says so if
|
|
213
|
-
the two versions have drifted apart.
|
|
214
|
-
|
|
215
|
-
A window's `size` and `position` are finite pixel numbers or linear
|
|
216
|
-
expressions. Fractions and percentages are equivalent relative terms, so
|
|
217
|
-
`"1/2"` and `"50%"` mean the same thing; pixel offsets may be combined with
|
|
218
|
-
them, as in `"50% + 10"`. Every value survives derivation unchanged.
|
|
219
|
-
|
|
220
|
-
## development — what `phresh dev` needs
|
|
221
|
-
|
|
222
|
-
`phresh init` offers to configure development for each declared half. It uses
|
|
223
|
-
the project's `dev` script as a suggested command when one exists, but records
|
|
224
|
-
nothing unless the author chooses it. If development is left unconfigured,
|
|
225
|
-
`phresh dev` refuses and names the declarations it needs:
|
|
226
|
-
|
|
227
|
-
```
|
|
228
|
-
Nothing here says how this program is developed.
|
|
229
|
-
|
|
230
|
-
Say how the server runs or where the client is served:
|
|
231
|
-
|
|
232
|
-
server: { …, development: { startCommand: "tsx source/server/main.ts" } }
|
|
233
|
-
client: { …, development: { url: "http://localhost:5173", startCommand: "bun run dev" } }
|
|
234
|
-
```
|
|
235
|
-
|
|
236
|
-
Each half may carry a `development` block, but the two shapes are deliberately
|
|
237
|
-
different. A Server and its development block each select exactly one of
|
|
238
|
-
`startCommand` or `entryFile`. A command starts an isolated operating-system
|
|
239
|
-
process tree; an entry module runs as a Worker owned by the System. In
|
|
240
|
-
development, the directory containing `phresh.config.ts` becomes the derived
|
|
241
|
-
Server location. A client block requires an HTTP(S) `url`; development clients
|
|
242
|
-
are never resolved from filesystem paths.
|
|
243
|
-
|
|
244
|
-
An `entryFile` is a path inside its Server location. Packaging copies it with
|
|
245
|
-
the rest of that directory, and the System rejects a path that escapes those
|
|
246
|
-
files. A Worker has no independent process working directory and is not a
|
|
247
|
-
security boundary; resolve module-owned resources with `import.meta.url` and
|
|
248
|
-
use the Server SDK for Program storage.
|
|
249
|
-
|
|
250
|
-
The client development shape may also declare `startCommand`. `phresh dev`
|
|
251
|
-
runs it from the project directory as a foreground development tool; the
|
|
252
|
-
command is never derived into the Program sent to the system. The tool and
|
|
253
|
-
the attached Program share one lifetime, so ending either ends the other.
|
|
254
|
-
|
|
255
|
-
Before launching the Program, `phresh dev` waits up to 15 seconds for the client
|
|
256
|
-
development URL to respond. While it remains unavailable, the URL is printed
|
|
257
|
-
every two seconds. A command that exits first is reported immediately. This
|
|
258
|
-
means the window is never deliberately opened onto a client that the authoring
|
|
259
|
-
tool already knows is unavailable.
|
|
260
|
-
|
|
261
|
-
## init
|
|
262
|
-
|
|
263
|
-
`phresh init` turns an existing package into a Program project. It reads the
|
|
264
|
-
identity, version, and description from `package.json`, ensures the project has
|
|
265
|
-
the matching `@phreshos/core` development dependency, and writes the typed
|
|
266
|
-
`phresh.config.ts` authoring description.
|
|
267
|
-
|
|
268
|
-
In a terminal, `init` asks for the production locations and Server execution
|
|
269
|
-
modes needed by `start` and `install`, including whether a package build should
|
|
270
|
-
prepare those locations. It then offers the development Server mode, Client
|
|
271
|
-
command, and URL needed by `dev`.
|
|
272
|
-
Existing `build` and `dev` package scripts become editable suggestions, never
|
|
273
|
-
silent assumptions. A single Endpoint defaults to `dist`; when both Endpoints
|
|
274
|
-
exist, their defaults are `dist/server` and `dist/client`. API documentation is
|
|
275
|
-
opt-in and defaults to disabled even when a likely document already exists.
|
|
49
|
+
System installation acquires and verifies the official release archive and
|
|
50
|
+
configures the native per-user service. Starting and stopping control current
|
|
51
|
+
execution; enabling and disabling control automatic startup.
|
|
276
52
|
|
|
277
|
-
|
|
278
|
-
named options:
|
|
53
|
+
## Runtime
|
|
279
54
|
|
|
280
|
-
```
|
|
281
|
-
phresh
|
|
282
|
-
|
|
283
|
-
|
|
284
|
-
|
|
285
|
-
|
|
286
|
-
|
|
287
|
-
phresh
|
|
288
|
-
--server-location dist \
|
|
289
|
-
--server-start-command "node main.js"
|
|
55
|
+
```sh
|
|
56
|
+
phresh program list
|
|
57
|
+
phresh process list --program my-program
|
|
58
|
+
phresh endpoint inspect \
|
|
59
|
+
--program my-program \
|
|
60
|
+
--process main \
|
|
61
|
+
--endpoint server
|
|
62
|
+
phresh window inspect --program my-program --process main
|
|
290
63
|
```
|
|
291
64
|
|
|
292
|
-
|
|
293
|
-
|
|
294
|
-
|
|
295
|
-
A Program must declare a Server endpoint, a Client endpoint, or both. Neither is
|
|
296
|
-
refused during the interview rather than at the border, which is the
|
|
297
|
-
earliest place it can be refused.
|
|
298
|
-
|
|
299
|
-
The final `Next` line is derived from the resulting config. It always shows
|
|
300
|
-
`phresh start` and `phresh install`; it shows `phresh dev` only when at least
|
|
301
|
-
one Endpoint received a development declaration.
|
|
302
|
-
|
|
303
|
-
Visual and advanced runtime defaults remain for the author to add deliberately:
|
|
304
|
-
`icon`, `size`, `position`, `installCommand`, `start`, layers, and minimization
|
|
305
|
-
are not guessed. An omitted `start` is `true`; only a default-off Endpoint needs to
|
|
306
|
-
say `start: false`.
|
|
307
|
-
|
|
308
|
-
## start and dev
|
|
309
|
-
|
|
310
|
-
Both **run your program without installing it, and stay attached.** They
|
|
311
|
-
print the `program.json` it will be declared as, hand that to the system
|
|
312
|
-
through the socket below the selected system home. With no override, that is
|
|
313
|
-
`~/.phreshos/gateway.sock`. Set `PHRESHOS_HOME` to an absolute system home to
|
|
314
|
-
address another system instance; the CLI derives
|
|
315
|
-
`<PHRESHOS_HOME>/gateway.sock` from it. The socket is not selected
|
|
316
|
-
separately from its instance. Only your account can open it, so nothing is
|
|
317
|
-
sent to prove anything, and then the command holds.
|
|
318
|
-
|
|
319
|
-
**The connection is the tether, in both directions.** Ctrl-C and your
|
|
320
|
-
program stops. Close the window it opened and the command returns, with
|
|
321
|
-
your program's own exit status as its own. Its `stdout` and `stderr`
|
|
322
|
-
arrive in your terminal as well as its system log. The system always
|
|
323
|
-
drains a server process; attachment adds the terminal as an audience
|
|
324
|
-
rather than changing how the process starts.
|
|
325
|
-
|
|
326
|
-
Nothing has to promise to clean up, which is the point — a promise would
|
|
327
|
-
not survive `kill -9`, a closed terminal, or a dropped ssh session. All
|
|
328
|
-
three end the command without running a line of it, and all three still
|
|
329
|
-
close the socket, which is what the system is watching.
|
|
330
|
-
|
|
331
|
-
**Attached means not installed; installed means persistent.** A program
|
|
332
|
-
meant to outlive your terminal is installed rather than run.
|
|
333
|
-
|
|
334
|
-
The run is registered as an ordinary uninstalled Program under the identity
|
|
335
|
-
declared by this project. Before registration, the system ends and forgets any
|
|
336
|
-
runtime Program already using that identity, whether it was installed or
|
|
337
|
-
uninstalled. Forgetting never uninstalls: installed files and storage remain
|
|
338
|
-
untouched while the attached Program becomes the sole runtime occupant. Its
|
|
339
|
-
root process tethers the whole Program to this command; when it exits, remaining
|
|
340
|
-
processes end and the runtime record disappears. A later `phresh install` can
|
|
341
|
-
replace the preserved installed files and immediately register the identity as
|
|
342
|
-
installed again. If no system is listening, the gateway says so plainly rather
|
|
343
|
-
than exposing `ENOENT`.
|
|
344
|
-
|
|
345
|
-
An attached Program still owns persistent project storage. The authoring tool
|
|
346
|
-
declares `<project>/storage` explicitly, so `start` and `dev` keep the same
|
|
347
|
-
database, store, data, cache, and logs as any other runtime form without
|
|
348
|
-
inventing a path from the system's working directory. Installation changes
|
|
349
|
-
where Program files are laid out; it does not change the logging contract.
|
|
350
|
-
|
|
351
|
-
They are one derivation over one config, differing only in where each
|
|
352
|
-
half is said to be:
|
|
65
|
+
The command hierarchy follows the runtime ownership hierarchy. Unknown
|
|
66
|
+
commands, flags, and malformed values reject rather than being guessed.
|
|
353
67
|
|
|
354
|
-
|
|
355
|
-
|
|
356
|
-
|
|
357
|
-
|
|
358
|
-
| `dev` | project root for a declared server development block; `development.url` for a declared client block | server absolute, client URL |
|
|
359
|
-
|
|
360
|
-
Every derived filesystem path is absolute because relative paths resolve
|
|
361
|
-
against the `program.json` they were read from, and a derived one does not live
|
|
362
|
-
beside your source. A client development URL remains the URL the author wrote.
|
|
363
|
-
|
|
364
|
-
## install
|
|
365
|
-
|
|
366
|
-
**A program has two ways of being used: run it, or install it.**
|
|
367
|
-
|
|
368
|
-
```bash
|
|
369
|
-
phresh install # this project, laid out on this machine
|
|
370
|
-
phresh install flambo # the official Flambo Program
|
|
68
|
+
```sh
|
|
69
|
+
phresh describe
|
|
70
|
+
phresh describe program
|
|
71
|
+
phresh describe process list
|
|
371
72
|
```
|
|
372
73
|
|
|
373
|
-
|
|
374
|
-
|
|
375
|
-
names into place — your program's parts are already on this disk at the
|
|
376
|
-
locations it names, so there is nothing an archive would carry that the
|
|
377
|
-
description does not already point at. `phresh pack` is for when you have
|
|
378
|
-
somewhere to send a program; installing here is a different act.
|
|
379
|
-
|
|
380
|
-
With a name, the CLI resolves and verifies that official Program's production
|
|
381
|
-
release directly; the current directory is irrelevant.
|
|
382
|
-
|
|
383
|
-
If `buildCommand` is declared, it completes successfully before anything is
|
|
384
|
-
sent to the system. Without it, install uses the production files exactly as
|
|
385
|
-
they stand.
|
|
74
|
+
`describe` exposes the command tree and exact options as machine-readable
|
|
75
|
+
contracts.
|
|
386
76
|
|
|
387
|
-
|
|
388
|
-
marked installed, and reconstructed after a restart. Running is the other one:
|
|
389
|
-
`phresh start` / `phresh dev` register it under its declared identity and
|
|
390
|
-
attach its whole lifetime to your terminal.
|
|
77
|
+
## Development
|
|
391
78
|
|
|
392
|
-
|
|
393
|
-
|
|
394
|
-
|
|
395
|
-
|
|
396
|
-
When a Server declares `installCommand`, `phresh install` writes that command's
|
|
397
|
-
`stdout` and `stderr` chunks as the System emits them. The final installed
|
|
398
|
-
confirmation appears only after the output stream completes successfully.
|
|
399
|
-
|
|
400
|
-
That is also why it names **paths** rather than sending bytes: install
|
|
401
|
-
used to want an upload because the installer was a browser, which has
|
|
402
|
-
bytes and no path. You have the paths.
|
|
403
|
-
|
|
404
|
-
## uninstall
|
|
405
|
-
|
|
406
|
-
```bash
|
|
407
|
-
phresh uninstall
|
|
408
|
-
phresh uninstall flambo
|
|
409
|
-
phresh uninstall --everything
|
|
79
|
+
```sh
|
|
80
|
+
bun install --frozen-lockfile
|
|
81
|
+
bun run verify
|
|
410
82
|
```
|
|
411
83
|
|
|
412
|
-
|
|
413
|
-
|
|
414
|
-
ends those Processes, removes everything the system owns for the Program, and
|
|
415
|
-
forgets its runtime record.
|
|
84
|
+
`verify` checks the scripts, builds the CLI and bundled starter, runs the
|
|
85
|
+
command tests, and validates the package artifact.
|
|
416
86
|
|
|
417
|
-
|
|
418
|
-
|
|
419
|
-
ordered `stdout` and `stderr` chunks as they arrive. A failed cleanup command
|
|
420
|
-
aborts removal and reports the failure.
|
|
87
|
+
See the [CLI documentation](https://github.com/PhreshOS/docs/blob/main/content/docs/sdks/cli.mdx)
|
|
88
|
+
for the command model.
|
|
421
89
|
|
|
422
|
-
|
|
423
|
-
With a name, the installed Program is addressed directly and the current
|
|
424
|
-
directory is irrelevant.
|
|
90
|
+
## Repository boundary
|
|
425
91
|
|
|
426
|
-
|
|
92
|
+
This repository owns terminal interaction, project commands, packaging, System
|
|
93
|
+
acquisition, and host service integration. Node owns the external JavaScript
|
|
94
|
+
interface, Core owns shared contracts, and the System owns authoritative state.
|
|
427
95
|
|
|
428
|
-
|
|
429
|
-
|
|
430
|
-
inside the archive. Your program may leave its halves anywhere; the
|
|
431
|
-
package always keeps them in the same places, so the artifact's shape
|
|
432
|
-
belongs to the contract rather than to your project. That is why the
|
|
433
|
-
`program.json` it writes names `server` and `client` explicitly — those
|
|
434
|
-
are the canonical locations the package just created. An explicit
|
|
435
|
-
`start: false` crosses with its half; an omitted value remains omitted
|
|
436
|
-
and means `true`. At least one declared half must resolve to true.
|
|
96
|
+
See [CONTRIBUTING.md](CONTRIBUTING.md) for the repository workflow and
|
|
97
|
+
[SECURITY.md](SECURITY.md) for private vulnerability reporting.
|
|
437
98
|
|
|
438
|
-
|
|
439
|
-
optional `icon.png`, and optional `agent.md` sit at the package's root. The
|
|
440
|
-
system names the directory it installs into from your program's `identity`.
|
|
441
|
-
An authored agent document may use any project-relative path, while packaging
|
|
442
|
-
normalizes it to `agent.md`.
|
|
99
|
+
## License
|
|
443
100
|
|
|
444
|
-
|
|
445
|
-
still the only declaration the system and release catalog read. Root
|
|
446
|
-
`categories`, `keywords`, and `website` values are optional and cross into it
|
|
447
|
-
without affecting execution. The file is generated output; `phresh.config.ts`
|
|
448
|
-
remains the authored source.
|
|
101
|
+
Licensed under the [MIT License](LICENSE). Copyright © 2026 Zohayr SLILEH.
|
package/dist/template/README.md
CHANGED
|
@@ -1,16 +1,23 @@
|
|
|
1
1
|
# Phresh Program
|
|
2
2
|
|
|
3
|
-
The minimal
|
|
4
|
-
there is no MVC structure and no registered service.
|
|
3
|
+
The official minimal starter Program generated by `phresh create`.
|
|
5
4
|
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
5
|
+
It demonstrates one Client and one Server communicating directly through the
|
|
6
|
+
standard PhreshOS Endpoint contracts.
|
|
7
|
+
|
|
8
|
+
## Create a Program
|
|
9
|
+
|
|
10
|
+
```sh
|
|
11
|
+
phresh create
|
|
9
12
|
```
|
|
10
13
|
|
|
11
|
-
The
|
|
14
|
+
The CLI bundles a verified release of this repository and creates the new
|
|
15
|
+
project without requiring a live template checkout.
|
|
16
|
+
|
|
17
|
+
## Structure
|
|
12
18
|
|
|
13
19
|
```text
|
|
20
|
+
phresh.config.ts
|
|
14
21
|
client/
|
|
15
22
|
├── app.tsx
|
|
16
23
|
├── index.html
|
|
@@ -18,8 +25,42 @@ client/
|
|
|
18
25
|
└── style.css
|
|
19
26
|
server/
|
|
20
27
|
└── main.ts
|
|
28
|
+
scripts/
|
|
29
|
+
└── build.ts
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
The Server owns the counter. The Client renders it and communicates with its
|
|
33
|
+
paired Server. The example deliberately has no additional MVC hierarchy and no
|
|
34
|
+
registered Service.
|
|
35
|
+
|
|
36
|
+
## Development
|
|
37
|
+
|
|
38
|
+
```sh
|
|
39
|
+
bun install --frozen-lockfile
|
|
40
|
+
bun run verify
|
|
41
|
+
bun run dev
|
|
21
42
|
```
|
|
22
43
|
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
44
|
+
Build, attach the production definition, or package the Program with:
|
|
45
|
+
|
|
46
|
+
```sh
|
|
47
|
+
bun run build
|
|
48
|
+
bun run start
|
|
49
|
+
bun run pack
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
`verify` checks the source, builds both Endpoints, and validates the packaged
|
|
53
|
+
Program shape.
|
|
54
|
+
|
|
55
|
+
## Repository boundary
|
|
56
|
+
|
|
57
|
+
This repository owns the starter source distributed by the CLI. It remains a
|
|
58
|
+
complete ordinary Program rather than a second template model or generator-only
|
|
59
|
+
fixture.
|
|
60
|
+
|
|
61
|
+
See [CONTRIBUTING.md](CONTRIBUTING.md) for the repository workflow and
|
|
62
|
+
[SECURITY.md](SECURITY.md) for private vulnerability reporting.
|
|
63
|
+
|
|
64
|
+
## License
|
|
65
|
+
|
|
66
|
+
Licensed under the [MIT License](LICENSE). Copyright © 2026 Zohayr SLILEH.
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "phresh",
|
|
3
3
|
"private": true,
|
|
4
|
-
"version": "0.1.
|
|
4
|
+
"version": "0.1.27",
|
|
5
5
|
"description": "The official PhreshOS starter Program.",
|
|
6
6
|
"type": "module",
|
|
7
7
|
"scripts": {
|
|
@@ -14,21 +14,21 @@
|
|
|
14
14
|
"starter"
|
|
15
15
|
],
|
|
16
16
|
"dependencies": {
|
|
17
|
-
"@phreshos/client": "^0.1.
|
|
18
|
-
"@phreshos/core": "^0.1.
|
|
19
|
-
"@phreshos/react": "^0.1.
|
|
20
|
-
"@phreshos/server": "^0.1.
|
|
17
|
+
"@phreshos/client": "^0.1.32",
|
|
18
|
+
"@phreshos/core": "^0.1.36",
|
|
19
|
+
"@phreshos/react": "^0.1.18",
|
|
20
|
+
"@phreshos/server": "^0.1.35",
|
|
21
21
|
"react": "^19.2.8",
|
|
22
22
|
"react-dom": "^19.2.8"
|
|
23
23
|
},
|
|
24
24
|
"devDependencies": {
|
|
25
|
-
"@phreshos/cli": "^0.1.
|
|
26
|
-
"@types/node": "^26.
|
|
25
|
+
"@phreshos/cli": "^0.1.44",
|
|
26
|
+
"@types/node": "^26.4.0",
|
|
27
27
|
"@types/react": "^19.2.18",
|
|
28
|
-
"@types/react-dom": "^19.2.
|
|
29
|
-
"@vitejs/plugin-react": "^6.
|
|
28
|
+
"@types/react-dom": "^19.2.5",
|
|
29
|
+
"@vitejs/plugin-react": "^6.1.1",
|
|
30
30
|
"typescript": "^7.0.2",
|
|
31
|
-
"vite": "^8.2.
|
|
31
|
+
"vite": "^8.2.2",
|
|
32
32
|
"vite-node": "^6.0.0"
|
|
33
33
|
}
|
|
34
34
|
}
|
|
@@ -4,7 +4,7 @@ export default defineConfig({
|
|
|
4
4
|
identity: "phresh",
|
|
5
5
|
name: "Phresh Program",
|
|
6
6
|
description: "A minimal counter with direct Client and Server endpoints.",
|
|
7
|
-
version: "0.1.
|
|
7
|
+
version: "0.1.27",
|
|
8
8
|
icon: "icon.png",
|
|
9
9
|
categories: ["Development"],
|
|
10
10
|
keywords: ["example", "counter", "client", "server"],
|
package/dist/template.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"repository": "PhreshOS/phresh-program",
|
|
3
|
-
"version": "0.1.
|
|
4
|
-
"sha256": "
|
|
3
|
+
"version": "0.1.27",
|
|
4
|
+
"sha256": "2655c450c1067ebd3bede8100b03adf1469d147124efa320f2c4c76914f20f4d",
|
|
5
5
|
"development": true
|
|
6
6
|
}
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@phreshos/cli",
|
|
3
3
|
"type": "module",
|
|
4
|
-
|
|
4
|
+
"version": "0.1.44",
|
|
5
5
|
"description": "The Phresh command-line interface for Program projects and system management.",
|
|
6
6
|
"engines": {
|
|
7
7
|
"node": ">=20.10"
|
|
@@ -49,8 +49,8 @@
|
|
|
49
49
|
"packageManager": "bun@1.3.14",
|
|
50
50
|
"dependencies": {
|
|
51
51
|
"@clack/prompts": "^1.7.0",
|
|
52
|
-
|
|
53
|
-
|
|
52
|
+
"@phreshos/core": "^0.1.36",
|
|
53
|
+
"@phreshos/node": "^0.1.12",
|
|
54
54
|
"adm-zip": "^0.6.0",
|
|
55
55
|
"commander": "^15.0.0",
|
|
56
56
|
"picocolors": "^1.1.1"
|