@profile-as-code/cli 0.2.0 → 0.3.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/README.md +52 -8
- package/dist/index.js +1286 -971
- package/package.json +2 -2
package/README.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# `@profile-as-code/cli` — `pasco`
|
|
2
2
|
|
|
3
|
-
The `pasco` CLI — `@profile-as-code/cli
|
|
3
|
+
The `pasco` CLI — `@profile-as-code/cli`. Consumes `@profile-as-code/core`
|
|
4
4
|
(`load`/`driftCheck`/`geoCheck`/`compile`) — it never re-implements them. The
|
|
5
5
|
contract source is `schema/profile.schema.json` (D3); Zod is generated in core.
|
|
6
6
|
|
|
@@ -8,18 +8,47 @@ contract source is `schema/profile.schema.json` (D3); Zod is generated in core.
|
|
|
8
8
|
|
|
9
9
|
```sh
|
|
10
10
|
npm i -g @profile-as-code/cli # the package
|
|
11
|
-
pasco --version # the bin —
|
|
11
|
+
pasco --version # the bin — prints the installed version
|
|
12
12
|
```
|
|
13
13
|
|
|
14
14
|
`@profile-as-code/cli` is the **package**; `pasco` is the **bin** it installs.
|
|
15
15
|
The install adds one global bin and nothing else: no post-install script, no
|
|
16
16
|
server, no account.
|
|
17
17
|
|
|
18
|
-
> **
|
|
19
|
-
>
|
|
20
|
-
>
|
|
21
|
-
>
|
|
22
|
-
>
|
|
18
|
+
> **Published** [OFICIAL] [WEB: registry.npmjs.org, checked 2026-10-09]:
|
|
19
|
+
> `@profile-as-code/cli` is public on npm — the registry is the source of truth
|
|
20
|
+
> (`npm view @profile-as-code/cli version`). The `0.2.0` release (published
|
|
21
|
+
> 2026-10-09T23:25:23Z; tag `v0.2.0` → `c1ca30c`) was verified running
|
|
22
|
+
> (`npx @profile-as-code/cli@0.2.0 --version` → `pasco 0.2.0`).
|
|
23
|
+
> Source install: [User Guide §2](../../docs/USER-GUIDE.md#2-install-the-pasco-cli).
|
|
24
|
+
|
|
25
|
+
## Get a workspace
|
|
26
|
+
|
|
27
|
+
`pasco` reads a **workspace folder** (`content/*.yaml` + `.pascorc`) by configured
|
|
28
|
+
path. That folder does not have to be a git repository, and it does not have to live
|
|
29
|
+
on GitHub — a repo is the **recommended** place to keep it, not a requirement
|
|
30
|
+
([SPEC §9](../../docs/SPEC.md)). Three on-ramps, each with its capability difference
|
|
31
|
+
stated up front:
|
|
32
|
+
|
|
33
|
+
| On-ramp | What you get | Automation + history | Account + repo |
|
|
34
|
+
|---|---|---|---|
|
|
35
|
+
| **Template repo** *(recommended)* | the complete example workspace, operational docs, licence, repo automation | yes | **required** |
|
|
36
|
+
| **`pasco init`** (this package) | a minimal validating folder in seconds | **no** — nothing runs on a change and nothing versions it | **none** |
|
|
37
|
+
| **Bring your own storage** | the same `pasco init` scaffold, written at a path you choose (local disk, a synced folder, another git host) | same as `pasco init` | **none** |
|
|
38
|
+
|
|
39
|
+
```sh
|
|
40
|
+
pasco init ~/profile-data-me # person flavor (default); brand: --flavor brand
|
|
41
|
+
pasco validate # run from the workspace root
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
The two no-account on-ramps keep the whole engine command set except `pasco diff`
|
|
45
|
+
(which needs a git history). What they lose is the template's automation and
|
|
46
|
+
history — `pasco init` is minimal on purpose, and the complete package lives in
|
|
47
|
+
the template. **Where each on-ramp is discovered:** the template repo's own README,
|
|
48
|
+
this package page, and — in the repository — the
|
|
49
|
+
[User Guide §3](../../docs/USER-GUIDE.md#3-create-your-workspace-profile-data-username)
|
|
50
|
+
(EN). Links into `docs/` resolve in the repository, not on this npm page: the two
|
|
51
|
+
commands above are the standalone path.
|
|
23
52
|
|
|
24
53
|
## Commands
|
|
25
54
|
|
|
@@ -78,10 +107,25 @@ file) > current directory.
|
|
|
78
107
|
{
|
|
79
108
|
"workspace": ".",
|
|
80
109
|
"defaults": { "lang": "en", "variants": 3 },
|
|
81
|
-
"diff": { "tagPattern": "release-*" }
|
|
110
|
+
"diff": { "tagPattern": "release-*" },
|
|
111
|
+
"completeness": {
|
|
112
|
+
"target": "github-milestone",
|
|
113
|
+
"langs": ["en", "es"],
|
|
114
|
+
"items": [
|
|
115
|
+
{ "id": "deployment", "weight": 0 },
|
|
116
|
+
{ "id": "geoAnchors", "weight": 0.4 }
|
|
117
|
+
]
|
|
118
|
+
}
|
|
82
119
|
}
|
|
83
120
|
```
|
|
84
121
|
|
|
122
|
+
The `completeness` block is the policy for `pasco status --completeness` (issue
|
|
123
|
+
#102): `target` names the milestone; `langs` sets which languages text coverage is
|
|
124
|
+
measured in; `items` overrides the shipped weights per catalog id (a weight of `0`
|
|
125
|
+
drops the item from the percentage). Every field is optional — omitted fields use
|
|
126
|
+
`DEFAULT_COMPLETENESS_POLICY`. The percentage itself is **derived** and never
|
|
127
|
+
written to the workspace; only this policy is stored.
|
|
128
|
+
|
|
85
129
|
## Exit codes
|
|
86
130
|
|
|
87
131
|
| Code | Meaning |
|