apcore-cli 0.10.4 → 0.11.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 +57 -0
- package/dist/bin/apcore-cli.js +1 -1
- package/dist/bin/apcore-cli.js.map +1 -1
- package/dist/index.js +1 -1
- package/dist/index.js.map +1 -1
- package/package.json +15 -6
package/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,63 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
|
|
|
6
6
|
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
7
7
|
|
|
8
8
|
|
|
9
|
+
## [0.11.0] - 2026-09-02
|
|
10
|
+
|
|
11
|
+
Bumps the required `apcore-js` floor to `0.28.0` and `apcore-toolkit` to `0.10.2` to track the aligned apcore 0.28.0 release (2026-08-31). One display fix (see Fixed) plus new regression tests take the suite from 653 to 661; `tsc --noEmit` and `eslint` pass unchanged. The argument-scoped approval path was verified end-to-end against the 0.28.0 runtime rather than inferred from the release notes.
|
|
12
|
+
|
|
13
|
+
**Why a minor rather than a patch.** This SDK needed no correctness fix of its own, but the three CLI SDKs ship as one version line, and the `apcli health` summary output changes here too. Version-locking them is what keeps the compatibility table and the cross-SDK conformance fixtures meaningful; see apcore-cli-python 0.11.0 for the changes that set the bump.
|
|
14
|
+
|
|
15
|
+
### Changed
|
|
16
|
+
|
|
17
|
+
- **`apcore-js>=0.28.0`, `apcore-toolkit>=0.10.2`** (peer and dev dependencies). apcore-toolkit 0.10.2 is a dependency-tracking release with no source change.
|
|
18
|
+
|
|
19
|
+
### Fixed
|
|
20
|
+
|
|
21
|
+
- **The `apcli health` summary line reported "no data" for a project whose modules it had just listed.** apcore classifies module health in **four** tiers — `healthy` / `degraded` / `error` / `unknown` — and the tally iterated only the first three. `unknown` means "no calls recorded yet", which is the state every module in a fresh project is in, so the common case rendered a populated table above a total that denied it:
|
|
22
|
+
|
|
23
|
+
```
|
|
24
|
+
probe.echo unknown 0.0% --
|
|
25
|
+
Summary: no data
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
**Pre-existing, and not introduced by this upgrade** — all three SDKs have emitted `unknown` since the tier set existed. apcore 0.28.0 is what brought it into focus: `sys-health-summary.schema.json` had declared the enum as `["healthy", "degraded", "unhealthy"]`, a value **no SDK emits**, and the release corrects it to the four tiers actually produced, splitting the summary's `unhealthy` count field into `error` and `unknown`. With the canonical shape finally naming four tiers, rendering three is a plain omission. Fixed in all three SDKs together, with the tally now covering `unknown`; a genuinely empty tally still reads "no data".
|
|
29
|
+
|
|
30
|
+
### Added
|
|
31
|
+
|
|
32
|
+
- **`tests/acl-argument-scoped-approval.test.ts` (4 cases)** pins the cross-SDK contract that an ACL-sourced approval requirement reaches `CliApprovalHandler`. Three cases assert the happy path and the `validate()` union; the fourth is the discriminating one — with auto-approve off and no TTY the handler refuses, so the ungated call must still succeed while the `--force` call must reject. Without that pair a gate that never fired would pass the suite.
|
|
33
|
+
|
|
34
|
+
- **Exit-code map parity pinned across the three SDKs.** A mechanical three-way diff of the maps found `DEPENDENCY_NOT_FOUND` and `DEPENDENCY_VERSION_MISMATCH` mapped to 44 here and in the other non-Rust SDK, but falling through to 1 in apcore-cli-rust (fixed in its 0.11.0). Both codes now carry an explicit assertion here too, so the three maps cannot drift again without a test going red.
|
|
35
|
+
|
|
36
|
+
- **`apcore-js` added to `devDependencies`** (it was declared only as a peer). The new conformance test is the first in this suite to import it, and a peer dependency is by contract supplied by the consumer — its presence during `pnpm install` here rests on `auto-install-peers` defaulting to on. `apcore-toolkit` has always been declared in both places for exactly this reason; `apcore-js` now matches. Verified with `rm -rf node_modules && pnpm install`.
|
|
37
|
+
|
|
38
|
+
- **The discriminating approval tests no longer depend on stdin not being a terminal.** They originally used `CliApprovalHandler` with auto-approve off and relied on its non-TTY refusal, which is not a property of the test — it is a property of how the suite happens to be launched. `cargo test` does not redirect stdin, so run from an interactive shell the Rust case printed its prompt, blocked for the full 60-second timeout and then failed on `ApprovalTimeout` instead of `ApprovalDenied`; `pytest -s` and a main-thread vitest configuration reach the same trap. All three now register a small recording stub that always refuses, which removes the ambient dependency and lets each test assert the stronger property directly: that the gate consulted a handler **at all**, and for exactly which call. The real `CliApprovalHandler` is still exercised, on the auto-approve path, where its answer is deterministic.
|
|
39
|
+
|
|
40
|
+
### Notes
|
|
41
|
+
|
|
42
|
+
- **The one 0.28.0 change that reaches this SDK works correctly and needed no code.** Spec v1.28.0 §6.9 makes the approval gate fire on the union of three sources, so an ACL rule carrying `approval: required` (§6.1.6) now routes calls to modules annotated `requiresApproval: false` through `CliApprovalHandler`. Verified against the runtime with a `git.push` module annotated `requiresApproval: false` behind an `arguments: { has_key: ["force"] }` approval rule: the plain call ran ungated, `--force` reached the handler, and `executor.validate()` reported `requiresApproval` as `false` and `true` respectively. `CliApprovalHandler.requestApproval` returns a plain object, which `ApprovalResult` accepts because it is a structurally-typed interface — apcore-cli-python returned the same shape against a dataclass and had to be fixed in its 0.11.0.
|
|
43
|
+
|
|
44
|
+
`requestApproval`'s two defensive short-circuits (`request.requires_approval === false`, `request.module_def?.annotations?.requires_approval === false`) stay inert against a real `ApprovalRequest`: the interface carries neither field, and §7.3's "`requiresApproval` is guaranteed true" now holds for an ACL-sourced requirement too — `builtin-steps.ts` rewrites the annotation before constructing the request.
|
|
45
|
+
|
|
46
|
+
- **What the 0.27.0 → 0.28.0 delta does *not* touch.** The CLI never constructs or loads an `ACL`, never calls `check()` / `checkAccess()` (so §6.8.1's fail-closed legacy boolean does not reach it), never reads an `AuditEntry`, and never builds an `ACLRule` (so §6.1.5's `effect` value closure and the new `approval` field are inert here). `ExecutionPolicy.resolve()`'s new optional `PolicyCallSite` parameter is additive and the CLI configures no policy. `p99_latency_ms` is display-only in `formatUsageSummaryTty`.
|
|
47
|
+
|
|
48
|
+
- **`system.usage.*` now rejects a malformed `--period` at the schema boundary.** `inputSchema` declares `pattern: '^[1-9][0-9]*[hd]$'`, so `apcli usage --period 0h` — passed through verbatim, as it always was — now fails with `SCHEMA_VALIDATION_ERROR` instead of `parsePeriod` throwing a plain `Error` from inside `execute()`. `exitCodeForError` already reads the wire code, so the exit code is 45 either way; only the message changes. The accepted set is unchanged.
|
|
49
|
+
|
|
50
|
+
- **`Executor.validate()` now reports the governance-effective requirement (§7.9.5)**, so `apcli validate` and the `--dry-run` path — which forward `result.requiresApproval` verbatim — correctly report a call gated only by an ACL argument-scoped rule.
|
|
51
|
+
|
|
52
|
+
## [0.10.5] - 2026-08-17
|
|
53
|
+
|
|
54
|
+
Patch release. Bumps the required `apcore-js` floor to `0.27.0` to track the aligned apcore 0.27.0 release (2026-08-14). **No source changes** — the full test suite (653 tests across 30 files) plus `tsc --noEmit` and `build` pass unchanged against apcore-js 0.27.0.
|
|
55
|
+
|
|
56
|
+
The apcore-js 0.26.0 → 0.27.0 delta is BREAKING at the spec level, but touches no surface the CLI consumes — verified against the release notes and the actual call sites:
|
|
57
|
+
|
|
58
|
+
- **Middleware semantics** — `beforeStep` failure is now terminal/non-recoverable, `afterStep` fires after a recovered step body. The CLI never constructs or configures middleware or pipelines; it only consumes injected `registry` / `executor` objects and introspects `describePipeline` / `currentStrategy.steps` (read-only). No exposure.
|
|
59
|
+
- **ACL-failed `validate()` introspection** — a failed `acl` check now withholds `module_preflight` / `module_preview` checks and `predictedChanges`. The CLI's `--dry-run` / `apcli validate` consume `PreflightResult.valid` / `checks` / `requiresApproval` (never `predictedChanges`); `--dry-run --trace` prints a hardcoded preset step list, not SDK data. ACL-denied results still map to exit 77 via the hardcoded check-name map in `output.ts` (acl→77) or the `ACL_DENIED` error code. No code change needed.
|
|
60
|
+
- **`Registry.register` metadata `dependencies` persistence** — the CLI never calls `register`; registration runs via the SDK's `discover()` (sandbox runner) or host-injected registries. The `--deps` column reads top-level `dependencies` (already always-empty in 0.26.0); 0.27.0 persistence under metadata does not regress it. No exposure.
|
|
61
|
+
- **Schema conversion (A23)** — object detection, nullable `anyOf` wrapping, sorted `required` are SDK-conversion rules. The CLI runs its **own** schema→Commander converter (`schema-parser.ts` / `ref-resolver.ts`) on the descriptor's `inputSchema`; `required` is order-insensitive. Nullable `{anyOf:[orig,{type:null}]}` properties fall to the "no type → string + warning" path — a behavior nuance, not a break (matches v0.10.3's Python-side fix).
|
|
62
|
+
- **`pipeline.configure` 4-field set / `requires`/`provides` non-configurable** — the CLI never configures pipelines; a host config carrying other keys now fails at load (spec-mandated strictness, upstream concern). `Config.get(key)` used by `apcli config get` is unaffected — required-field validation applies to the load/validate path, which the CLI never invokes.
|
|
63
|
+
- **No type coercion at the module boundary** — the CLI already performs its own coercion (Commander `parseArg`, `reconvertEnumValues`) before `executor.execute`, so CLI-passed values are typed already.
|
|
64
|
+
- **Removed root exports** — `CTX_TRACING_SPAN_ID`, `OtelTracer`, `OtelSpan`, `TracingMiddlewareOptions` are no longer exported from `apcore-js` 0.27.0 — none imported by this CLI. (`ExecutionPolicy.fromObject` boolean strictness is host-side.)
|
|
65
|
+
|
|
9
66
|
## [0.10.4] - 2026-07-14
|
|
10
67
|
|
|
11
68
|
Patch release. Bumps the required `apcore-js` floor to `0.26.0` to align the ecosystem on the 0.26.0 governance layer (additive, no breaking changes). No code or API changes.
|
package/dist/bin/apcore-cli.js
CHANGED
|
@@ -3229,7 +3229,7 @@ function formatHealthSummaryTty(result) {
|
|
|
3229
3229
|
);
|
|
3230
3230
|
}
|
|
3231
3231
|
const parts = [];
|
|
3232
|
-
for (const key of ["healthy", "degraded", "error"]) {
|
|
3232
|
+
for (const key of ["healthy", "degraded", "error", "unknown"]) {
|
|
3233
3233
|
const count = summary[key];
|
|
3234
3234
|
if (count) parts.push(`${count} ${key}`);
|
|
3235
3235
|
}
|