@automatify-au/cli 0.1.12 → 0.1.14

package/README.md

@@ -85,7 +85,7 @@ automatify testops config set forgeEndpoint "<webtrigger-url>"
 printf "%s" "$TESTOPS_FORGE_AUTH_TOKEN" | automatify testops config set forgeAuthToken --stdin
 ```
 
-`forgeAuthToken` local storage currently uses macOS Keychain. On Windows, Linux, and CI, keep the token in `TESTOPS_FORGE_AUTH_TOKEN` instead. `.testops-cli.json` should store non-secret values only.
+`forgeAuthToken` local storage uses macOS Keychain on macOS and current-user Windows DPAPI on Windows. Linux and CI should keep the token in `TESTOPS_FORGE_AUTH_TOKEN`. `.testops-cli.json` stores non-secret values plus, on Windows, only the DPAPI-protected blob. See [WINDOWS.md](./WINDOWS.md) for PowerShell setup and verification.
 
 Optional:
 - `TESTOPS_FORGE_TIMEOUT_MS`
@@ -261,7 +261,7 @@ Current authentication boundary:
 - Setup does not turn this into an all-user auth model. Customer-admin packaging and any future user-level authentication remain separate work.
 - The same callback key may be stored as a GitHub Actions repository secret only under the explicit `github-secrets` apply scope.
 
-Azure DevOps follow-up is deliberately outside this stage. The next adapter should reuse the same plan/apply/doctor orchestration and mutation scopes, map Azure organization/project/pipeline/ref fields into the existing `azureDevops` Forge profile config, manage callback pipeline variables through stdin/safe references, inspect pipeline metadata without queueing a run, and preserve the same confirmation/idempotency/redaction rules.
+Azure DevOps setup uses the same plan/apply/doctor safety boundary. Generate a plan with `--provider azure-devops`, mapping `--organization`, `--azure-project`, `--pipeline-id`, and `--ref` into the existing `azureDevops` Forge profile. Callback pipeline variables are accepted only through stdin or `--secret-ref key=env:NAME`; dry-run, explicit approval, idempotency, and redaction are identical to GitHub setup. Doctor inspects pipeline metadata and variable names only; it never queues a pipeline run.
 
 ## Allure Evidence for Jira
 
@@ -308,7 +308,7 @@ Machine-readable output:
 automatify testops allure upload ABC-123 ./allure-report.zip --dry-run --json
 ```
 
-After a real upload, JSON output includes Jira attachment metadata when Jira returns it:
+After a real upload, JSON output includes Jira attachment metadata when Jira returns them:
 
 ```json
 {
@@ -427,7 +427,7 @@ export JIRA_BASE_URL="https://automatify-com-au.atlassian.net"
 export JIRA_PROJECT_KEY="DEV"
 ```
 
-Or store the non-secret values in `.testops-cli.json` and, on macOS, the token in Keychain:
+Or store the non-secret values in `.testops-cli.json`; on macOS the token is stored in Keychain, and on Windows it is protected with current-user DPAPI:
 ```bash
 automatify testops config set baseUrl https://automatify-com-au.atlassian.net
 automatify testops config set projectKey DEV
@@ -435,7 +435,7 @@ automatify testops config set forgeEndpoint "<webtrigger-url>"
 printf "%s" "$TESTOPS_FORGE_AUTH_TOKEN" | automatify testops config set forgeAuthToken --stdin
 ```
 
-Windows, Linux, and CI should keep the token in environment variables:
+On Linux and CI, keep the token in environment variables. Windows users can use the same `config set forgeAuthToken --stdin` flow from PowerShell; see [WINDOWS.md](./WINDOWS.md).
 ```bash
 export TESTOPS_FORGE_AUTH_TOKEN="<one-time-token-from-forge-ui>"
 ```