@configdirector/cli 0.8.0-beta.1 → 0.10.0-beta.1

package/CHANGELOG.md

@@ -4,6 +4,31 @@ All notable changes to `@configdirector/cli` are documented here. The format fol
 
 ## [Unreleased]
 
+## [0.10.0-beta.1] - 2026-10-19
+
+### Added
+
+- The CLI keeps one sign-in per organization, so you can work for two organizations from one machine. `configdirector login` asks ConfigDirector which organization the pasted token belongs to and saves the token as the sign-in for that organization, with the organization's id and name, in `sign-ins.json` in the same directory `config.json` was in, readable only by your user. Signing in again with a token of the same organization replaces that sign-in; a token of another organization adds one. A token without `projects:read` is refused and nothing is saved. `--json` prints the file and the organization's id and name.
+- `configdirector.json` holds `organization`, the id of the project's organization, which `init` now writes after `project`. A command in that directory uses the sign-in for that organization, and exits with 2 before changing anything when the token it was given, such as a `CONFIGDIRECTOR_TOKEN` set for an MCP server, belongs to another organization that has a project with the same slug. A file without `organization` is not checked, so a file from an earlier version works as before.
+- `--organization <name or id>` and `CONFIGDIRECTOR_ORGANIZATION` pick the sign-in to use, by the organization's saved name, matched whatever its case, or its id, ahead of `organization` in `configdirector.json`. Giving either together with `--token` or `CONFIGDIRECTOR_TOKEN`, or to `login`, exits with 2. Without them and without `organization` in the file, the only sign-in is used, and two or more sign-ins exit with 2 naming them.
+- `init` looks for the project through every sign-in, or through the sign-in `--organization` names, or through `--token` or `CONFIGDIRECTOR_TOKEN` alone. A slug that two organizations have exits with 2 naming them and asking for `--organization`; a slug none has exits with 2 naming the organizations searched. On an existing `configdirector.json` without `organization`, `init` adds it, taking the project from the file and keeping every other field; a `--project` other than the file's exits with 2, and a file that already has `organization` is still refused. `--json` adds `organizationId`.
+- `configdirector logout` removes the sign-in the commands in the current directory would use, chosen as above, and says the token keeps working until it is revoked on the dashboard's API tokens page. It sends no request, so `CONFIGDIRECTOR_TOKEN` does not stop it; `--token` exits with 2. `--json` prints `{ "removedSignIn": { "organization": { "id": "...", "name": "..." } } }`.
+- `configdirector api-token get` shows the token a command in the current directory would use: its organization's name and id, its name, its permissions, when it expires, and whether it came from `--token`, `CONFIGDIRECTOR_TOKEN` or a sign-in. It never shows the token itself. `--json` prints the Admin API's response as received. It needs a valid token with any permissions.
+
+### Changed
+
+- The first command that reads the sign-ins after the upgrade, `login` and `logout` included, moves the token saved by an earlier version in `config.json` into a sign-in, with one request to learn its organization, and deletes `config.json`. A token ConfigDirector no longer accepts is deleted without becoming a sign-in, with a line on stderr saying so; when the Admin API cannot be reached, `config.json` stays for the next run. A command whose token comes from `--token` or `CONFIGDIRECTOR_TOKEN` neither reads the sign-ins nor moves the token.
+- `login --json` prints `signInsFile` in place of `tokenFile`, and `login` reads the token with `GET /api-token` rather than by listing the projects.
+- `init` prints the project's organization, by its saved name or, with `--token` or `CONFIGDIRECTOR_TOKEN`, by its id.
+
+## [0.9.0-beta.1] - 2026-10-18
+
+### Added
+
+- `configdirector scan --json` prints, and `scan --upload` sends, a snippet with each direct and indirect reference: its line and the 2 lines before and after it, so the dashboard can show the code around the reference. A snippet stops at the start and end of the file, leaves out line endings, and cuts a line longer than 250 characters to its first 250, listing it in `truncatedLines`. Dynamic references have no snippet, and the text output is unchanged. `schema/scan-output.schema.json` describes the `snippet` field.
+- `--context-lines <number>` sets how many lines before and after each reference the snippet includes, from 0 to 5; `--context-lines 0` includes the reference line alone. `--no-snippets` sends no snippet. Giving both, or a `--context-lines` that is not a whole number from 0 to 5, exits with 2.
+- When the project's Code snippets setting is off, `scan --upload` sends no snippets and ends with `Code snippets were not sent: this project does not store them.` `scan` without `--upload` still prints them with `--json`.
+
 ## [0.8.0-beta.1] - 2026-10-18
 
 ### Added

package/README.md

@@ -1,6 +1,6 @@
 # ConfigDirector CLI
 
-`configdirector` is the command line tool for [ConfigDirector](https://www.configdirector.com), the managed configuration and feature flag service. It is in beta: commands and output may change before 1.0. This release signs in, links a repository to a project, lists where the repository's code reads config keys, checks those keys against the project's configs, shows the value a context gets for a config and why, reads a project's environments, configs, targeting rules and segments, creates configs, replaces a config's targeting rules in an environment, archives configs, uploads the repository's code references to the project, and lists and removes the project's scanned repositories.
+`configdirector` is the command line tool for [ConfigDirector](https://www.configdirector.com), the managed configuration and feature flag service. It is in beta: commands and output may change before 1.0. This release signs in to one or more organizations, links a repository to a project, lists where the repository's code reads config keys, checks those keys against the project's configs, shows the value a context gets for a config and why, reads a project's environments, configs, targeting rules and segments, creates configs, replaces a config's targeting rules in an environment, archives configs, uploads the repository's code references to the project, and lists and removes the project's scanned repositories.
 
 The [CLI page of the ConfigDirector docs](https://docs.configdirector.com/integrations/cli) covers the API token, CI setup for GitHub Actions and GitLab, and what each problem `validate` reports means for your build.
 
@@ -20,7 +20,7 @@ Create an API token in the ConfigDirector dashboard, then run:
 configdirector login
 ```
 
-The token is saved for later runs, where only you can read it. In CI, set `CONFIGDIRECTOR_TOKEN` instead.
+The token is saved as your sign-in for its organization, where only you can read it. You keep one sign-in per organization: run `login` again with a token of another organization to add one, and `configdirector logout` removes the sign-in the commands in the current directory would use. `configdirector api-token get` shows which token a command there would use, with its organization, name, permissions and expiration. In CI, set `CONFIGDIRECTOR_TOKEN` instead.
 
 ## Link a repository to a project
 
@@ -30,7 +30,7 @@ From the repository root:
 configdirector init --project <project-slug>
 ```
 
-This writes `configdirector.json`. Commit it so every run and every CI job uses the same project.
+This writes `configdirector.json` with the project's slug and the id of its organization. Commit it so every run and every CI job uses the same project. `init` looks for the project through each of your sign-ins, so with two organizations each repository links to its own, and a command in the repository uses that organization's sign-in. A token from another organization, such as a `CONFIGDIRECTOR_TOKEN` set for an MCP server, is refused there.
 
 ## Find where the code reads configs
 
@@ -54,6 +54,8 @@ The scan skips what `.gitignore` ignores, the `node_modules`, `vendor`, `build`,
 
 With `--json`, `scan` prints the references for scripts and CI; `schema/scan-output.schema.json` in the package describes that output. Each reference has a `kind`, `direct` or `indirect`, and a direct reference resolved from a constant carries the constant as `argument`.
 
+Each direct and indirect reference in the JSON also carries a `snippet`: its line and the 2 lines before and after it, without line endings, with any line longer than 250 characters cut to its first 250. `--context-lines <number>` includes from 0 to 5 lines on each side, and `--no-snippets` leaves every snippet out; giving both exits with 2. Dynamic references have no snippet, and the text output shows none.
+
 ## Upload the scan to ConfigDirector
 
 From the repository root, on the default branch:
@@ -68,6 +70,8 @@ The repository is named after the path of its git remote `origin`, without the h
 
 The upload holds the references and dynamic references `scan --json` prints, whatever `ignoreKeys` lists, except a reference to a key that cannot be a config key, such as one shorter than 4 characters, which is left out and counted. The output is the scan's, then a line naming the repository, the commit, the project, how many references were sent and how many were left out. A scan that finds no source file exits with 2 and uploads nothing, so a wrong path or `include` never empties the repository's references; a scan that reads files and finds no reference uploads an empty set. With `--json`, it prints the Admin API's response as received.
 
+Each direct and indirect reference is sent with its snippet, so the dashboard can show the code around it; `--no-snippets` sends no code, and `--context-lines` sets how many lines are sent. When the project's Code snippets setting is off, `scan --upload` sends no snippets and ends with `Code snippets were not sent: this project does not store them.`
+
 A project holds at most 50 scanned repositories, and one upload holds at most 10,000 references, dynamic references included; going over either exits with 2. `scan --upload` needs `projects:read`, `configs:read` and `code-references:update`. Uploads do not appear in the audit log.
 
 ## List and remove scanned repositories
@@ -115,6 +119,18 @@ A test client call, such as `setValue` or `createTestClient`, is checked for unk
 
 The output lists the problems grouped by kind, with the file, the line, the key and what is wrong, such as the type a timespan is served as, then counts the references checked. With `--json`, `validate` prints the scan's JSON with a `findings` array; `schema/scan-output.schema.json` describes it.
 
+## GitHub Action
+
+The [ConfigDirector Code Scan](https://github.com/ConfigDirector/scan-code) action runs `validate` on pull requests, and `validate` then `scan --upload` on pushes to the default branch:
+
+```yaml
+- uses: ConfigDirector/scan-code@v1
+  with:
+    token: ${{ secrets.CONFIGDIRECTOR_TOKEN }}
+```
+
+Its README lists the inputs and the permissions the token needs for each step.
+
 ## See what a context gets for a config
 
 ```bash
@@ -276,12 +292,13 @@ It asks for no confirmation and does not check whether the code still reads the
 
 ## Options
 
-| Option             | Environment variable      | Meaning                                                                                                       |
-| ------------------ | ------------------------- | ------------------------------------------------------------------------------------------------------------- |
-| `--token <token>`  | `CONFIGDIRECTOR_TOKEN`    | API token. Without either, the token saved by `login` is used.                                                |
-| `--base-url <url>` | `CONFIGDIRECTOR_BASE_URL` | API host. Defaults to `https://api.configdirector.com`.                                                       |
-| `--project <slug>` | `CONFIGDIRECTOR_PROJECT`  | Project slug. Without either, every command that reads a project uses the `project` in `configdirector.json`. |
-| `--json`           |                           | Print JSON on stdout. Errors always go to stderr.                                                             |
+| Option                        | Environment variable          | Meaning                                                                                                                                                           |
+| ----------------------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `--token <token>`             | `CONFIGDIRECTOR_TOKEN`        | API token. Without either, the sign-in saved by `login` for the organization named below is used, or the only sign-in.                                            |
+| `--organization <name or id>` | `CONFIGDIRECTOR_ORGANIZATION` | The organization whose sign-in to use, by its saved name or its id. Without either, the `organization` in `configdirector.json`. Cannot be combined with a token. |
+| `--base-url <url>`            | `CONFIGDIRECTOR_BASE_URL`     | API host. Defaults to `https://api.configdirector.com`.                                                                                                           |
+| `--project <slug>`            | `CONFIGDIRECTOR_PROJECT`      | Project slug. Without either, every command that reads a project uses the `project` in `configdirector.json`.                                                     |
+| `--json`                      |                               | Print JSON on stdout. Errors always go to stderr.                                                                                                                 |
 
 The command exits with 0 when it succeeds, 1 when `validate` found a problem or `configs create` found a config that already has the key, and 2 when it could not run: a usage mistake, a rejected token, a suspended service, an unreachable API, or something the command names that does not exist, such as a config key, an environment, a saved context, a segment key, a tag or a scanned repository. A CI job can therefore tell a wrong config key from an outage.