@seliseblocks/cli-os 0.1.1 → 0.1.2
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/AI_USAGE_GUIDE.md +305 -305
- package/LICENSE +21 -21
- package/README.md +159 -159
- package/bin/run.js +2 -2
- package/dist/commands/auth/status.js +5 -1
- package/dist/commands/doctor.js +9 -4
- package/dist/index.js +147 -147
- package/dist/lib/config.d.ts +1 -0
- package/dist/lib/token.d.ts +3 -0
- package/dist/lib/token.js +34 -3
- package/package.json +47 -47
package/AI_USAGE_GUIDE.md
CHANGED
|
@@ -1,305 +1,305 @@
|
|
|
1
|
-
# Blocks OS CLI Guide for AI Agents
|
|
2
|
-
|
|
3
|
-
This guide is for AI agents using the published `@seliseblocks/cli-os` npm package. The installed binary is `blocks-os`.
|
|
4
|
-
|
|
5
|
-
Use `blocks-os` as the control plane. If a capability exists in the CLI, call the CLI from the terminal instead of calling Blocks cloud APIs directly from ad hoc scripts or generated application code.
|
|
6
|
-
|
|
7
|
-
## Install
|
|
8
|
-
|
|
9
|
-
Install the package in the environment where the agent will operate:
|
|
10
|
-
|
|
11
|
-
```bash
|
|
12
|
-
npm install -g @seliseblocks/cli-os
|
|
13
|
-
```
|
|
14
|
-
|
|
15
|
-
Verify the binary:
|
|
16
|
-
|
|
17
|
-
```bash
|
|
18
|
-
blocks-os --version
|
|
19
|
-
blocks-os --help
|
|
20
|
-
```
|
|
21
|
-
|
|
22
|
-
For local package development only, contributors may run `node bin/run.js ...` from the source repository. AI agents consuming the npm package should use `blocks-os ...`.
|
|
23
|
-
|
|
24
|
-
## Operating Rules
|
|
25
|
-
|
|
26
|
-
- Use `blocks-os ...` for all supported Blocks OS, IAM, Data, Release, and scaffold operations.
|
|
27
|
-
- Prefer `--json` for automation and parsing.
|
|
28
|
-
- Use `--dry-run` before any mutating command.
|
|
29
|
-
- Do not run real mutating cloud commands unless the user explicitly approved the exact action.
|
|
30
|
-
- Never print, commit, scaffold, or document client secrets, access tokens, refresh tokens, cookies, or JWTs.
|
|
31
|
-
- Treat any secret pasted into chat or logs as exposed and rotate it before production use.
|
|
32
|
-
- Generated apps must not contain CLI client secrets or CLI tokens.
|
|
33
|
-
- If a CLI command returns an error, fix or report the CLI path. Do not bypass the CLI with a one-off API request when the command exists.
|
|
34
|
-
|
|
35
|
-
## Account Setup
|
|
36
|
-
|
|
37
|
-
Add the CLI OIDC account:
|
|
38
|
-
|
|
39
|
-
```bash
|
|
40
|
-
blocks-os auth:add --client-id <clientId> --client-secret <clientSecret>
|
|
41
|
-
```
|
|
42
|
-
|
|
43
|
-
Normal production defaults are built in:
|
|
44
|
-
|
|
45
|
-
```text
|
|
46
|
-
API URL: https://api.seliseblocks.com
|
|
47
|
-
OIDC URL: https://iam.seliseblocks.com
|
|
48
|
-
OS portal URL: https://os.seliseblocks.com
|
|
49
|
-
Redirect URI: http://127.0.0.1:8976/callback
|
|
50
|
-
Scope: openid profile offline_access
|
|
51
|
-
Root tenant: d7e5554c758541db8a18694b64ef423d
|
|
52
|
-
```
|
|
53
|
-
|
|
54
|
-
The CLI stores client secrets and OAuth tokens in the OS credential backend when available. Do not manually copy token files between machines.
|
|
55
|
-
|
|
56
|
-
## Login
|
|
57
|
-
|
|
58
|
-
Use browser login when an interactive browser is available:
|
|
59
|
-
|
|
60
|
-
```bash
|
|
61
|
-
blocks-os login
|
|
62
|
-
```
|
|
63
|
-
|
|
64
|
-
Use device login when a browser callback is not convenient:
|
|
65
|
-
|
|
66
|
-
```bash
|
|
67
|
-
blocks-os login:device
|
|
68
|
-
```
|
|
69
|
-
|
|
70
|
-
Check current auth state:
|
|
71
|
-
|
|
72
|
-
```bash
|
|
73
|
-
blocks-os auth:status --json
|
|
74
|
-
```
|
|
75
|
-
|
|
76
|
-
Repair stale or corrupted local auth storage:
|
|
77
|
-
|
|
78
|
-
```bash
|
|
79
|
-
blocks-os auth:repair --yes
|
|
80
|
-
blocks-os auth:add --client-id <clientId> --client-secret <clientSecret>
|
|
81
|
-
blocks-os login
|
|
82
|
-
```
|
|
83
|
-
|
|
84
|
-
## Project Workflow
|
|
85
|
-
|
|
86
|
-
List projects:
|
|
87
|
-
|
|
88
|
-
```bash
|
|
89
|
-
blocks-os projects:list --json
|
|
90
|
-
```
|
|
91
|
-
|
|
92
|
-
Create a project only after explicit user approval:
|
|
93
|
-
|
|
94
|
-
```bash
|
|
95
|
-
blocks-os projects:create <projectName> --env dev --dry-run --json
|
|
96
|
-
blocks-os projects:create <projectName> --env dev --yes --json
|
|
97
|
-
```
|
|
98
|
-
|
|
99
|
-
Select a project:
|
|
100
|
-
|
|
101
|
-
```bash
|
|
102
|
-
blocks-os use <projectTenantId>
|
|
103
|
-
```
|
|
104
|
-
|
|
105
|
-
Read the selected project:
|
|
106
|
-
|
|
107
|
-
```bash
|
|
108
|
-
blocks-os projects:get --json
|
|
109
|
-
```
|
|
110
|
-
|
|
111
|
-
## Scaffold a Web App
|
|
112
|
-
|
|
113
|
-
Generate a React/Vite Blocks app:
|
|
114
|
-
|
|
115
|
-
```bash
|
|
116
|
-
blocks-os new web <appName> --x-blocks-key <projectTenantId> --app-domain <appDomainOrUrl> --blocks-api-url https://api.seliseblocks.com
|
|
117
|
-
```
|
|
118
|
-
|
|
119
|
-
If a public browser OIDC client exists for the app, include it:
|
|
120
|
-
|
|
121
|
-
```bash
|
|
122
|
-
blocks-os new web <appName> --x-blocks-key <projectTenantId> --app-domain <appDomainOrUrl> --blocks-api-url https://api.seliseblocks.com --client-id <publicOidcClientId>
|
|
123
|
-
```
|
|
124
|
-
|
|
125
|
-
Use `--oidc-url <url>` only for non-production IAM authority overrides; it defaults to `https://iam.seliseblocks.com`.
|
|
126
|
-
|
|
127
|
-
Validate the scaffold:
|
|
128
|
-
|
|
129
|
-
```bash
|
|
130
|
-
cd <appName>
|
|
131
|
-
npm install
|
|
132
|
-
npm run build
|
|
133
|
-
```
|
|
134
|
-
|
|
135
|
-
Do not pass the CLI client secret to the scaffolded app. Browser apps must use a public OIDC client and the SDK hosted IdP flow: `blocksClient.auth.idp.redirectToProvider()` on login click and `blocksClient.auth.idp.callback()` on `/login/callback`.
|
|
136
|
-
|
|
137
|
-
`--app-domain` is the app's real Blocks domain/origin, for example `https://dbpdba.seliseblocks.com`. The generated `.env` keeps that full value as `VITE_BLOCKS_APP_DOMAIN` and derives the local dev host without a scheme as `VITE_BLOCKS_DEV_HOST=dbpdba.seliseblocks.com`.
|
|
138
|
-
|
|
139
|
-
For local browser login on the real host domain:
|
|
140
|
-
|
|
141
|
-
1. Add `127.0.0.1 <VITE_BLOCKS_DEV_HOST>` to the hosts file.
|
|
142
|
-
2. Run `npm install`.
|
|
143
|
-
3. Run `npm run cert`.
|
|
144
|
-
4. Run `npm run dev`.
|
|
145
|
-
5. Open `https://<VITE_BLOCKS_DEV_HOST>:5173`, not plain `http://`.
|
|
146
|
-
|
|
147
|
-
The generated cert script uses the `selfsigned` Node dependency, so it works from normal PowerShell after `npm install`; do not tell Windows users to switch to Git Bash just for OpenSSL. If hosted login or secure cookies fail locally, confirm the app is opened with the HTTPS dev URL from `VITE_BLOCKS_DEV_HOST`.
|
|
148
|
-
|
|
149
|
-
## IAM
|
|
150
|
-
|
|
151
|
-
The CLI exposes only the current user:
|
|
152
|
-
|
|
153
|
-
```bash
|
|
154
|
-
blocks-os iam:me --json
|
|
155
|
-
```
|
|
156
|
-
|
|
157
|
-
Do not add IAM admin behavior outside the supported CLI commands unless the CLI package is explicitly extended and tested.
|
|
158
|
-
|
|
159
|
-
## Data
|
|
160
|
-
|
|
161
|
-
Validate local files:
|
|
162
|
-
|
|
163
|
-
```bash
|
|
164
|
-
blocks-os data:validate --json
|
|
165
|
-
```
|
|
166
|
-
|
|
167
|
-
List schemas:
|
|
168
|
-
|
|
169
|
-
```bash
|
|
170
|
-
blocks-os data:schema:list --json
|
|
171
|
-
```
|
|
172
|
-
|
|
173
|
-
Pull schemas:
|
|
174
|
-
|
|
175
|
-
```bash
|
|
176
|
-
blocks-os data:schema:pull --json
|
|
177
|
-
```
|
|
178
|
-
|
|
179
|
-
Push schemas only after dry-run and approval:
|
|
180
|
-
|
|
181
|
-
```bash
|
|
182
|
-
blocks-os data:schema:push --dry-run --json
|
|
183
|
-
blocks-os data:schema:push --yes --json
|
|
184
|
-
```
|
|
185
|
-
|
|
186
|
-
Pull rules:
|
|
187
|
-
|
|
188
|
-
```bash
|
|
189
|
-
blocks-os data:rules:pull --json
|
|
190
|
-
```
|
|
191
|
-
|
|
192
|
-
Deploy rules only after dry-run and approval:
|
|
193
|
-
|
|
194
|
-
```bash
|
|
195
|
-
blocks-os data:rules:deploy --dry-run --json
|
|
196
|
-
blocks-os data:rules:deploy --yes --json
|
|
197
|
-
```
|
|
198
|
-
|
|
199
|
-
Reload Data schema configuration only after approval:
|
|
200
|
-
|
|
201
|
-
```bash
|
|
202
|
-
blocks-os data:reload --dry-run --json
|
|
203
|
-
blocks-os data:reload --yes --json
|
|
204
|
-
```
|
|
205
|
-
|
|
206
|
-
## Localization
|
|
207
|
-
|
|
208
|
-
Generate or update local i18n dictionaries as JSON, then let the CLI sync them to Blocks Localization. Do not ask humans to manually copy keys into the portal.
|
|
209
|
-
|
|
210
|
-
Default file convention:
|
|
211
|
-
|
|
212
|
-
```text
|
|
213
|
-
blocks/localization/<module>.<language>.json
|
|
214
|
-
```
|
|
215
|
-
|
|
216
|
-
Example:
|
|
217
|
-
|
|
218
|
-
```json
|
|
219
|
-
{
|
|
220
|
-
"dashboard.title": "Dashboard",
|
|
221
|
-
"products.empty": "No products found"
|
|
222
|
-
}
|
|
223
|
-
```
|
|
224
|
-
|
|
225
|
-
Nested JSON is accepted on input and flattened before validation:
|
|
226
|
-
|
|
227
|
-
```json
|
|
228
|
-
{
|
|
229
|
-
"dashboard": {
|
|
230
|
-
"title": "Dashboard"
|
|
231
|
-
}
|
|
232
|
-
}
|
|
233
|
-
```
|
|
234
|
-
|
|
235
|
-
Validate first:
|
|
236
|
-
|
|
237
|
-
```bash
|
|
238
|
-
blocks-os localization:validate --module common --language en --json
|
|
239
|
-
```
|
|
240
|
-
|
|
241
|
-
Push only after dry-run and approval:
|
|
242
|
-
|
|
243
|
-
```bash
|
|
244
|
-
blocks-os localization:push --module common --language en --dry-run --json
|
|
245
|
-
blocks-os localization:push --module common --language en --yes --json
|
|
246
|
-
```
|
|
247
|
-
|
|
248
|
-
Pull published cloud localization when local fallback files need to be refreshed:
|
|
249
|
-
|
|
250
|
-
```bash
|
|
251
|
-
blocks-os localization:pull --module common --language en --json
|
|
252
|
-
```
|
|
253
|
-
|
|
254
|
-
Use Localization gateway v4 paths without `/api`: `/localization/v4/Module/Gets`, `/localization/v4/Module/Save`, `/localization/v4/Key/SaveKeys`, and `/localization/v4/Key/GetCloudUilmFile`.
|
|
255
|
-
|
|
256
|
-
## Release
|
|
257
|
-
|
|
258
|
-
Trigger a deploy only after dry-run and approval:
|
|
259
|
-
|
|
260
|
-
```bash
|
|
261
|
-
blocks-os release:deploy --repo-id <repoId> --dry-run --json
|
|
262
|
-
blocks-os release:deploy --repo-id <repoId> --yes --json
|
|
263
|
-
```
|
|
264
|
-
|
|
265
|
-
Read build status:
|
|
266
|
-
|
|
267
|
-
```bash
|
|
268
|
-
blocks-os release:status <buildId> --json
|
|
269
|
-
blocks-os release:builds:get <buildId> --json
|
|
270
|
-
```
|
|
271
|
-
|
|
272
|
-
List builds for a repository:
|
|
273
|
-
|
|
274
|
-
```bash
|
|
275
|
-
blocks-os release:builds:list --repo-id <repoId> --json
|
|
276
|
-
```
|
|
277
|
-
|
|
278
|
-
## Agent Failure Handling
|
|
279
|
-
|
|
280
|
-
- `not_logged_in`: run `blocks-os login`.
|
|
281
|
-
- `auth_repair_required`: run `blocks-os auth:repair --yes`, re-add credentials, then login.
|
|
282
|
-
- `project_not_selected`: run `blocks-os use <projectTenantId>`.
|
|
283
|
-
- `api_auth_failed`: run `blocks-os auth:status --json`, then login again.
|
|
284
|
-
- HTML returned from an API command means the command endpoint path is wrong and must be fixed in the CLI.
|
|
285
|
-
|
|
286
|
-
## Local Development Checks
|
|
287
|
-
|
|
288
|
-
These are for contributors maintaining the package, not for normal AI package consumers:
|
|
289
|
-
|
|
290
|
-
```bash
|
|
291
|
-
npm test
|
|
292
|
-
npm pack --dry-run
|
|
293
|
-
```
|
|
294
|
-
|
|
295
|
-
Live smoke checks after login:
|
|
296
|
-
|
|
297
|
-
```bash
|
|
298
|
-
blocks-os projects:list --json
|
|
299
|
-
blocks-os iam:me --json
|
|
300
|
-
blocks-os data:schema:list --json
|
|
301
|
-
```
|
|
302
|
-
|
|
303
|
-
## Security Boundary
|
|
304
|
-
|
|
305
|
-
The CLI may store secrets and tokens in the OS credential backend. Generated apps must not. The scaffolded app should receive only public runtime config such as API URL, project key, app domain, OIDC URL, and public OIDC client id.
|
|
1
|
+
# Blocks OS CLI Guide for AI Agents
|
|
2
|
+
|
|
3
|
+
This guide is for AI agents using the published `@seliseblocks/cli-os` npm package. The installed binary is `blocks-os`.
|
|
4
|
+
|
|
5
|
+
Use `blocks-os` as the control plane. If a capability exists in the CLI, call the CLI from the terminal instead of calling Blocks cloud APIs directly from ad hoc scripts or generated application code.
|
|
6
|
+
|
|
7
|
+
## Install
|
|
8
|
+
|
|
9
|
+
Install the package in the environment where the agent will operate:
|
|
10
|
+
|
|
11
|
+
```bash
|
|
12
|
+
npm install -g @seliseblocks/cli-os
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
Verify the binary:
|
|
16
|
+
|
|
17
|
+
```bash
|
|
18
|
+
blocks-os --version
|
|
19
|
+
blocks-os --help
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
For local package development only, contributors may run `node bin/run.js ...` from the source repository. AI agents consuming the npm package should use `blocks-os ...`.
|
|
23
|
+
|
|
24
|
+
## Operating Rules
|
|
25
|
+
|
|
26
|
+
- Use `blocks-os ...` for all supported Blocks OS, IAM, Data, Release, and scaffold operations.
|
|
27
|
+
- Prefer `--json` for automation and parsing.
|
|
28
|
+
- Use `--dry-run` before any mutating command.
|
|
29
|
+
- Do not run real mutating cloud commands unless the user explicitly approved the exact action.
|
|
30
|
+
- Never print, commit, scaffold, or document client secrets, access tokens, refresh tokens, cookies, or JWTs.
|
|
31
|
+
- Treat any secret pasted into chat or logs as exposed and rotate it before production use.
|
|
32
|
+
- Generated apps must not contain CLI client secrets or CLI tokens.
|
|
33
|
+
- If a CLI command returns an error, fix or report the CLI path. Do not bypass the CLI with a one-off API request when the command exists.
|
|
34
|
+
|
|
35
|
+
## Account Setup
|
|
36
|
+
|
|
37
|
+
Add the CLI OIDC account:
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
blocks-os auth:add --client-id <clientId> --client-secret <clientSecret>
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Normal production defaults are built in:
|
|
44
|
+
|
|
45
|
+
```text
|
|
46
|
+
API URL: https://api.seliseblocks.com
|
|
47
|
+
OIDC URL: https://iam.seliseblocks.com
|
|
48
|
+
OS portal URL: https://os.seliseblocks.com
|
|
49
|
+
Redirect URI: http://127.0.0.1:8976/callback
|
|
50
|
+
Scope: openid profile offline_access
|
|
51
|
+
Root tenant: d7e5554c758541db8a18694b64ef423d
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
The CLI stores client secrets and OAuth tokens in the OS credential backend when available. Do not manually copy token files between machines.
|
|
55
|
+
|
|
56
|
+
## Login
|
|
57
|
+
|
|
58
|
+
Use browser login when an interactive browser is available:
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
blocks-os login
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
Use device login when a browser callback is not convenient:
|
|
65
|
+
|
|
66
|
+
```bash
|
|
67
|
+
blocks-os login:device
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
Check current auth state:
|
|
71
|
+
|
|
72
|
+
```bash
|
|
73
|
+
blocks-os auth:status --json
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
Repair stale or corrupted local auth storage:
|
|
77
|
+
|
|
78
|
+
```bash
|
|
79
|
+
blocks-os auth:repair --yes
|
|
80
|
+
blocks-os auth:add --client-id <clientId> --client-secret <clientSecret>
|
|
81
|
+
blocks-os login
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
## Project Workflow
|
|
85
|
+
|
|
86
|
+
List projects:
|
|
87
|
+
|
|
88
|
+
```bash
|
|
89
|
+
blocks-os projects:list --json
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
Create a project only after explicit user approval:
|
|
93
|
+
|
|
94
|
+
```bash
|
|
95
|
+
blocks-os projects:create <projectName> --env dev --dry-run --json
|
|
96
|
+
blocks-os projects:create <projectName> --env dev --yes --json
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
Select a project:
|
|
100
|
+
|
|
101
|
+
```bash
|
|
102
|
+
blocks-os use <projectTenantId>
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
Read the selected project:
|
|
106
|
+
|
|
107
|
+
```bash
|
|
108
|
+
blocks-os projects:get --json
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
## Scaffold a Web App
|
|
112
|
+
|
|
113
|
+
Generate a React/Vite Blocks app:
|
|
114
|
+
|
|
115
|
+
```bash
|
|
116
|
+
blocks-os new web <appName> --x-blocks-key <projectTenantId> --app-domain <appDomainOrUrl> --blocks-api-url https://api.seliseblocks.com
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
If a public browser OIDC client exists for the app, include it:
|
|
120
|
+
|
|
121
|
+
```bash
|
|
122
|
+
blocks-os new web <appName> --x-blocks-key <projectTenantId> --app-domain <appDomainOrUrl> --blocks-api-url https://api.seliseblocks.com --client-id <publicOidcClientId>
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
Use `--oidc-url <url>` only for non-production IAM authority overrides; it defaults to `https://iam.seliseblocks.com`.
|
|
126
|
+
|
|
127
|
+
Validate the scaffold:
|
|
128
|
+
|
|
129
|
+
```bash
|
|
130
|
+
cd <appName>
|
|
131
|
+
npm install
|
|
132
|
+
npm run build
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
Do not pass the CLI client secret to the scaffolded app. Browser apps must use a public OIDC client and the SDK hosted IdP flow: `blocksClient.auth.idp.redirectToProvider()` on login click and `blocksClient.auth.idp.callback()` on `/login/callback`.
|
|
136
|
+
|
|
137
|
+
`--app-domain` is the app's real Blocks domain/origin, for example `https://dbpdba.seliseblocks.com`. The generated `.env` keeps that full value as `VITE_BLOCKS_APP_DOMAIN` and derives the local dev host without a scheme as `VITE_BLOCKS_DEV_HOST=dbpdba.seliseblocks.com`.
|
|
138
|
+
|
|
139
|
+
For local browser login on the real host domain:
|
|
140
|
+
|
|
141
|
+
1. Add `127.0.0.1 <VITE_BLOCKS_DEV_HOST>` to the hosts file.
|
|
142
|
+
2. Run `npm install`.
|
|
143
|
+
3. Run `npm run cert`.
|
|
144
|
+
4. Run `npm run dev`.
|
|
145
|
+
5. Open `https://<VITE_BLOCKS_DEV_HOST>:5173`, not plain `http://`.
|
|
146
|
+
|
|
147
|
+
The generated cert script uses the `selfsigned` Node dependency, so it works from normal PowerShell after `npm install`; do not tell Windows users to switch to Git Bash just for OpenSSL. If hosted login or secure cookies fail locally, confirm the app is opened with the HTTPS dev URL from `VITE_BLOCKS_DEV_HOST`.
|
|
148
|
+
|
|
149
|
+
## IAM
|
|
150
|
+
|
|
151
|
+
The CLI exposes only the current user:
|
|
152
|
+
|
|
153
|
+
```bash
|
|
154
|
+
blocks-os iam:me --json
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
Do not add IAM admin behavior outside the supported CLI commands unless the CLI package is explicitly extended and tested.
|
|
158
|
+
|
|
159
|
+
## Data
|
|
160
|
+
|
|
161
|
+
Validate local files:
|
|
162
|
+
|
|
163
|
+
```bash
|
|
164
|
+
blocks-os data:validate --json
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
List schemas:
|
|
168
|
+
|
|
169
|
+
```bash
|
|
170
|
+
blocks-os data:schema:list --json
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
Pull schemas:
|
|
174
|
+
|
|
175
|
+
```bash
|
|
176
|
+
blocks-os data:schema:pull --json
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
Push schemas only after dry-run and approval:
|
|
180
|
+
|
|
181
|
+
```bash
|
|
182
|
+
blocks-os data:schema:push --dry-run --json
|
|
183
|
+
blocks-os data:schema:push --yes --json
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
Pull rules:
|
|
187
|
+
|
|
188
|
+
```bash
|
|
189
|
+
blocks-os data:rules:pull --json
|
|
190
|
+
```
|
|
191
|
+
|
|
192
|
+
Deploy rules only after dry-run and approval:
|
|
193
|
+
|
|
194
|
+
```bash
|
|
195
|
+
blocks-os data:rules:deploy --dry-run --json
|
|
196
|
+
blocks-os data:rules:deploy --yes --json
|
|
197
|
+
```
|
|
198
|
+
|
|
199
|
+
Reload Data schema configuration only after approval:
|
|
200
|
+
|
|
201
|
+
```bash
|
|
202
|
+
blocks-os data:reload --dry-run --json
|
|
203
|
+
blocks-os data:reload --yes --json
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
## Localization
|
|
207
|
+
|
|
208
|
+
Generate or update local i18n dictionaries as JSON, then let the CLI sync them to Blocks Localization. Do not ask humans to manually copy keys into the portal.
|
|
209
|
+
|
|
210
|
+
Default file convention:
|
|
211
|
+
|
|
212
|
+
```text
|
|
213
|
+
blocks/localization/<module>.<language>.json
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
Example:
|
|
217
|
+
|
|
218
|
+
```json
|
|
219
|
+
{
|
|
220
|
+
"dashboard.title": "Dashboard",
|
|
221
|
+
"products.empty": "No products found"
|
|
222
|
+
}
|
|
223
|
+
```
|
|
224
|
+
|
|
225
|
+
Nested JSON is accepted on input and flattened before validation:
|
|
226
|
+
|
|
227
|
+
```json
|
|
228
|
+
{
|
|
229
|
+
"dashboard": {
|
|
230
|
+
"title": "Dashboard"
|
|
231
|
+
}
|
|
232
|
+
}
|
|
233
|
+
```
|
|
234
|
+
|
|
235
|
+
Validate first:
|
|
236
|
+
|
|
237
|
+
```bash
|
|
238
|
+
blocks-os localization:validate --module common --language en --json
|
|
239
|
+
```
|
|
240
|
+
|
|
241
|
+
Push only after dry-run and approval:
|
|
242
|
+
|
|
243
|
+
```bash
|
|
244
|
+
blocks-os localization:push --module common --language en --dry-run --json
|
|
245
|
+
blocks-os localization:push --module common --language en --yes --json
|
|
246
|
+
```
|
|
247
|
+
|
|
248
|
+
Pull published cloud localization when local fallback files need to be refreshed:
|
|
249
|
+
|
|
250
|
+
```bash
|
|
251
|
+
blocks-os localization:pull --module common --language en --json
|
|
252
|
+
```
|
|
253
|
+
|
|
254
|
+
Use Localization gateway v4 paths without `/api`: `/localization/v4/Module/Gets`, `/localization/v4/Module/Save`, `/localization/v4/Key/SaveKeys`, and `/localization/v4/Key/GetCloudUilmFile`.
|
|
255
|
+
|
|
256
|
+
## Release
|
|
257
|
+
|
|
258
|
+
Trigger a deploy only after dry-run and approval:
|
|
259
|
+
|
|
260
|
+
```bash
|
|
261
|
+
blocks-os release:deploy --repo-id <repoId> --dry-run --json
|
|
262
|
+
blocks-os release:deploy --repo-id <repoId> --yes --json
|
|
263
|
+
```
|
|
264
|
+
|
|
265
|
+
Read build status:
|
|
266
|
+
|
|
267
|
+
```bash
|
|
268
|
+
blocks-os release:status <buildId> --json
|
|
269
|
+
blocks-os release:builds:get <buildId> --json
|
|
270
|
+
```
|
|
271
|
+
|
|
272
|
+
List builds for a repository:
|
|
273
|
+
|
|
274
|
+
```bash
|
|
275
|
+
blocks-os release:builds:list --repo-id <repoId> --json
|
|
276
|
+
```
|
|
277
|
+
|
|
278
|
+
## Agent Failure Handling
|
|
279
|
+
|
|
280
|
+
- `not_logged_in`: run `blocks-os login`.
|
|
281
|
+
- `auth_repair_required`: run `blocks-os auth:repair --yes`, re-add credentials, then login.
|
|
282
|
+
- `project_not_selected`: run `blocks-os use <projectTenantId>`.
|
|
283
|
+
- `api_auth_failed`: run `blocks-os auth:status --json`, then login again.
|
|
284
|
+
- HTML returned from an API command means the command endpoint path is wrong and must be fixed in the CLI.
|
|
285
|
+
|
|
286
|
+
## Local Development Checks
|
|
287
|
+
|
|
288
|
+
These are for contributors maintaining the package, not for normal AI package consumers:
|
|
289
|
+
|
|
290
|
+
```bash
|
|
291
|
+
npm test
|
|
292
|
+
npm pack --dry-run
|
|
293
|
+
```
|
|
294
|
+
|
|
295
|
+
Live smoke checks after login:
|
|
296
|
+
|
|
297
|
+
```bash
|
|
298
|
+
blocks-os projects:list --json
|
|
299
|
+
blocks-os iam:me --json
|
|
300
|
+
blocks-os data:schema:list --json
|
|
301
|
+
```
|
|
302
|
+
|
|
303
|
+
## Security Boundary
|
|
304
|
+
|
|
305
|
+
The CLI may store secrets and tokens in the OS credential backend. Generated apps must not. The scaffolded app should receive only public runtime config such as API URL, project key, app domain, OIDC URL, and public OIDC client id.
|
package/LICENSE
CHANGED
|
@@ -1,21 +1,21 @@
|
|
|
1
|
-
MIT License
|
|
2
|
-
|
|
3
|
-
Copyright (c) SELISE Blocks
|
|
4
|
-
|
|
5
|
-
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
-
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
-
in the Software without restriction, including without limitation the rights
|
|
8
|
-
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
-
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
-
furnished to do so, subject to the following conditions:
|
|
11
|
-
|
|
12
|
-
The above copyright notice and this permission notice shall be included in all
|
|
13
|
-
copies or substantial portions of the Software.
|
|
14
|
-
|
|
15
|
-
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
-
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
-
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
-
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
-
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
-
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
-
SOFTWARE.
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) SELISE Blocks
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|