@rosthq/cli 0.7.123 → 0.7.124
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 +58 -0
- package/dist/commands/onboarding.d.ts +24 -2
- package/dist/commands/onboarding.d.ts.map +1 -1
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +829 -525
- package/dist/index.js.map +4 -4
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -96,6 +96,64 @@ rost onboard status
|
|
|
96
96
|
rost onboard resume
|
|
97
97
|
```
|
|
98
98
|
|
|
99
|
+
Every tenant-scoped `rost onboard` verb (and `rost seat create-complete`)
|
|
100
|
+
authenticates with an existing implementation-bootstrap credential first and
|
|
101
|
+
falls back to the user session, so the whole composite flow below runs without
|
|
102
|
+
a personal login. (`rost onboard run` prints the public onboarding prompt
|
|
103
|
+
offline and needs no credential.)
|
|
104
|
+
|
|
105
|
+
Retain each allowed local business source before constructing the setup plan.
|
|
106
|
+
The CLI reads the file and base64-encodes it client-side; the server computes
|
|
107
|
+
the digest and canonical family manifest and rejects paths, URLs, and
|
|
108
|
+
client-supplied digests:
|
|
109
|
+
|
|
110
|
+
```bash
|
|
111
|
+
rost onboard source-ingest \
|
|
112
|
+
--file ./org-chart.csv \
|
|
113
|
+
--source-key org-chart \
|
|
114
|
+
--kind org_chart \
|
|
115
|
+
--title "Org chart" \
|
|
116
|
+
--json
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
The JSON output contains the opaque `source_upload_id` and the exact
|
|
120
|
+
`source_ref` object to place in the setup plan's `sources[]`.
|
|
121
|
+
|
|
122
|
+
Transport note: the command body is capped server-side at 1 MiB, and base64
|
|
123
|
+
expands content by 4/3 — so the largest source file reachable through this
|
|
124
|
+
command today is about 780 KB, not the protocol's documented 5,000,000-byte
|
|
125
|
+
bound. The CLI checks this before sending and names the exact fitting size;
|
|
126
|
+
split or trim a larger export.
|
|
127
|
+
|
|
128
|
+
Stage the one-approval composite setup with the complete declarative plan
|
|
129
|
+
(`--input '<json>'` inline, or `--input-file <path>` for a large plan):
|
|
130
|
+
|
|
131
|
+
```bash
|
|
132
|
+
rost onboard setup --input-file ./setup-plan.json --json
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
Staging succeeds with exit code 0: the server holds the one owner approval and
|
|
136
|
+
the CLI prints the pending confirmation id and the exact approval URL (with
|
|
137
|
+
`--json`, the full pending-confirmation object including
|
|
138
|
+
`approveVia.webUrl`). Hand the human that one URL.
|
|
139
|
+
|
|
140
|
+
Discover the setup state through the command's idempotent contract by
|
|
141
|
+
re-submitting the identical plan:
|
|
142
|
+
|
|
143
|
+
```bash
|
|
144
|
+
rost onboard setup-status --input-file ./setup-plan.json --json
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
After the owner approves, this returns the immutable applied receipt — the
|
|
148
|
+
`application_id`, `receipt.receipt_revision`, and `receipt.digests.input` are
|
|
149
|
+
exactly the `--setup-application-id`, `--expected-receipt-revision`, and
|
|
150
|
+
`--expected-input-digest` the rehearsal step needs. While approval is still
|
|
151
|
+
pending, re-submission returns the current approval card: an identical
|
|
152
|
+
still-valid card is reused with the same confirmation id and URL; only a
|
|
153
|
+
changed server-derived projection (live state moved) supersedes the stale card
|
|
154
|
+
and mints a fresh one. After application, a same-key re-submission with a
|
|
155
|
+
*different* plan digest is a typed conflict, never a mutation.
|
|
156
|
+
|
|
99
157
|
After the owner approves the atomic setup proposal, run the exact receipt-bound
|
|
100
158
|
sandbox rehearsal:
|
|
101
159
|
|
|
@@ -5,17 +5,39 @@ type CliIo = {
|
|
|
5
5
|
};
|
|
6
6
|
export type OnboardingDeps = {
|
|
7
7
|
makeClient(): Promise<CommandClient>;
|
|
8
|
+
readFile?: (path: string) => Promise<Buffer>;
|
|
8
9
|
};
|
|
9
10
|
export type OnboardingInvocation = {
|
|
10
|
-
commandId: "onboarding.status" | "onboarding.resume" | "onboarding.rehearse" | "onboarding.activate";
|
|
11
|
+
commandId: "onboarding.status" | "onboarding.resume" | "onboarding.rehearse" | "onboarding.activate" | "onboarding.source_ingest" | "onboarding.setup";
|
|
11
12
|
body: Record<string, unknown>;
|
|
12
13
|
json: boolean;
|
|
13
|
-
action: "status" | "resume" | "rehearse" | "activate";
|
|
14
|
+
action: "status" | "resume" | "rehearse" | "activate" | "source-ingest" | "setup" | "setup-status";
|
|
15
|
+
sourceFile?: string;
|
|
16
|
+
inputFile?: string;
|
|
14
17
|
};
|
|
15
18
|
export declare class OnboardingUsageError extends Error {
|
|
16
19
|
constructor(message: string);
|
|
17
20
|
}
|
|
18
21
|
export declare function runOnboarding(args: string[], io: CliIo, deps: OnboardingDeps): Promise<number>;
|
|
22
|
+
/**
|
|
23
|
+
* Execute a parsed (file-resolved) invocation and render its result. Shared by
|
|
24
|
+
* the user-session path (runOnboarding) and the implementation-credential path
|
|
25
|
+
* in index.ts, so both credentials get identical bodies and rendering.
|
|
26
|
+
*
|
|
27
|
+
* `onError` lets the implementation-credential caller intercept a dead-run
|
|
28
|
+
* credential (fall through to the user session) before the error is printed.
|
|
29
|
+
*/
|
|
30
|
+
export declare function executeOnboardingInvocation(invocation: OnboardingInvocation, io: CliIo, client: CommandClient): Promise<number>;
|
|
31
|
+
export declare function executeOnboardingInvocation(invocation: OnboardingInvocation, io: CliIo, client: CommandClient, options: {
|
|
32
|
+
onError: (error: unknown) => "handled" | "print";
|
|
33
|
+
}): Promise<number | "fall-through">;
|
|
34
|
+
/**
|
|
35
|
+
* Resolve the local file reads a parsed invocation deferred: the source bytes
|
|
36
|
+
* behind `onboard source-ingest --file` (base64-encoded client-side; the server
|
|
37
|
+
* never accepts paths) and the JSON plan behind `--input-file`. Read failures
|
|
38
|
+
* surface as usage errors before any client is constructed.
|
|
39
|
+
*/
|
|
40
|
+
export declare function resolveOnboardingInvocationFiles(invocation: OnboardingInvocation, readFileImpl?: (path: string) => Promise<Buffer>): Promise<void>;
|
|
19
41
|
export declare function parseOnboardingInvocation(args: string[]): OnboardingInvocation;
|
|
20
42
|
export declare function onboardingUsage(): string;
|
|
21
43
|
export declare function formatOnboardingOutput(action: OnboardingInvocation["action"], output: unknown): string;
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"onboarding.d.ts","sourceRoot":"","sources":["../../src/commands/onboarding.ts"],"names":[],"mappings":"
|
|
1
|
+
{"version":3,"file":"onboarding.d.ts","sourceRoot":"","sources":["../../src/commands/onboarding.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,aAAa,EAAsB,MAAM,sBAAsB,CAAC;AAKzE,KAAK,KAAK,GAAG;IACX,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAC1C,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;CAC3C,CAAC;AAEF,MAAM,MAAM,cAAc,GAAG;IAI3B,UAAU,IAAI,OAAO,CAAC,aAAa,CAAC,CAAC;IAGrC,QAAQ,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC,CAAC;CAC9C,CAAC;AAmDF,MAAM,MAAM,oBAAoB,GAAG;IACjC,SAAS,EACL,mBAAmB,GACnB,mBAAmB,GACnB,qBAAqB,GACrB,qBAAqB,GACrB,0BAA0B,GAC1B,kBAAkB,CAAC;IACvB,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;IAC9B,IAAI,EAAE,OAAO,CAAC;IACd,MAAM,EAAE,QAAQ,GAAG,QAAQ,GAAG,UAAU,GAAG,UAAU,GAAG,eAAe,GAAG,OAAO,GAAG,cAAc,CAAC;IAInG,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB,CAAC;AAEF,qBAAa,oBAAqB,SAAQ,KAAK;gBACjC,OAAO,EAAE,MAAM;CAI5B;AAED,wBAAsB,aAAa,CAAC,IAAI,EAAE,MAAM,EAAE,EAAE,EAAE,EAAE,KAAK,EAAE,IAAI,EAAE,cAAc,GAAG,OAAO,CAAC,MAAM,CAAC,CAepG;AAED;;;;;;;GAOG;AACH,wBAAsB,2BAA2B,CAC/C,UAAU,EAAE,oBAAoB,EAChC,EAAE,EAAE,KAAK,EACT,MAAM,EAAE,aAAa,GACpB,OAAO,CAAC,MAAM,CAAC,CAAC;AACnB,wBAAsB,2BAA2B,CAC/C,UAAU,EAAE,oBAAoB,EAChC,EAAE,EAAE,KAAK,EACT,MAAM,EAAE,aAAa,EACrB,OAAO,EAAE;IAAE,OAAO,EAAE,CAAC,KAAK,EAAE,OAAO,KAAK,SAAS,GAAG,OAAO,CAAA;CAAE,GAC5D,OAAO,CAAC,MAAM,GAAG,cAAc,CAAC,CAAC;AAmCpC;;;;;GAKG;AACH,wBAAsB,gCAAgC,CACpD,UAAU,EAAE,oBAAoB,EAChC,YAAY,GAAE,CAAC,IAAI,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,CAAY,GACzD,OAAO,CAAC,IAAI,CAAC,CA8Cf;AA8DD,wBAAgB,yBAAyB,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,oBAAoB,CA+G9E;AA2FD,wBAAgB,eAAe,IAAI,MAAM,CASxC;AAED,wBAAgB,sBAAsB,CACpC,MAAM,EAAE,oBAAoB,CAAC,QAAQ,CAAC,EACtC,MAAM,EAAE,OAAO,GACd,MAAM,CAoBR"}
|
package/dist/index.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AAMA,OAAO,EAAE,aAAa,EAAsB,MAAM,qBAAqB,CAAC;AAExE,OAAO,EAAE,gBAAgB,EAAE,yBAAyB,EAAE,MAAM,WAAW,CAAC;AACxE,OAAO,EAAoB,mBAAmB,EAAE,MAAM,kBAAkB,CAAC;AACzE,OAAO,EAAoB,KAAK,UAAU,EAAE,MAAM,kBAAkB,CAAC;
|
|
1
|
+
{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AAMA,OAAO,EAAE,aAAa,EAAsB,MAAM,qBAAqB,CAAC;AAExE,OAAO,EAAE,gBAAgB,EAAE,yBAAyB,EAAE,MAAM,WAAW,CAAC;AACxE,OAAO,EAAoB,mBAAmB,EAAE,MAAM,kBAAkB,CAAC;AACzE,OAAO,EAAoB,KAAK,UAAU,EAAE,MAAM,kBAAkB,CAAC;AAoCrE,KAAK,KAAK,GAAG;IACX,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAC1C,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAI1C,WAAW,CAAC,EAAE,OAAO,CAAC;IAOtB,OAAO,CAAC,EAAE,CAAC,QAAQ,EAAE,MAAM,KAAK,OAAO,CAAC,OAAO,CAAC,CAAC;CAClD,CAAC;AAKF,wBAAgB,mBAAmB,CACjC,KAAK,EAAE,MAAM,CAAC,cAAc,EAC5B,MAAM,EAAE,MAAM,CAAC,cAAc,GAC5B,CAAC,QAAQ,EAAE,MAAM,KAAK,OAAO,CAAC,OAAO,CAAC,CAUxC;AAID,KAAK,WAAW,GAAG;IACjB,KAAK,CAAC,EAAE,UAAU,CAAC;IACnB,EAAE,CAAC,EAAE,KAAK,CAAC;IACX,KAAK,CAAC,EAAE,OAAO,gBAAgB,CAAC;IAChC,WAAW,CAAC,EAAE,OAAO,mBAAmB,CAAC;IACzC,cAAc,CAAC,EAAE,OAAO,yBAAyB,CAAC;IAGlD,aAAa,CAAC,EAAE,OAAO,aAAa,CAAC;CACtC,CAAC;AAEF,wBAAsB,IAAI,CAAC,IAAI,WAAwB,EAAE,OAAO,GAAE,WAAgB,GAAG,OAAO,CAAC,MAAM,CAAC,CAmenG;AA8gBD,wBAAgB,eAAe,CAAC,SAAS,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,SAAS,GAAG,OAAO,CAUxF"}
|