@theholocron/cli 5.0.0-alpha.20 → 5.0.0-alpha.200

package/README.md

@@ -17,33 +17,101 @@ holocron --help
 ## Interactive mode
 
 Run `holocron` with no command, a parent command with no subcommand
-(`holocron auth`, `holocron skills`, `holocron upgrade`), or a leaf command
-missing a required positional (`holocron deploy`, `holocron secret set`), and
-you get a prompt instead of a `--help` dead end:
+(`holocron auth`, `holocron repo`, `holocron repo upgrade`, …), or a leaf command
+missing a required positional (`holocron deploy`, `holocron secrets set`), and
+you get a prompt instead of a `--help` dead end.
+
+The menu mirrors the command tree: each level shows only the next word, and a
+group (marked `›`) opens its own submenu, as deep as the commands nest. Nothing
+is shown as a `<command> <subcommand>` path — `config show` is `config ›` then
+`show`. Every submenu has a `← back` item, and a command that is also a group
+(`repo sync`, `deploy`) has a `(run it)` item at the top of its submenu. Typing
+searches the whole tree — `upgrade` at the top finds the `repo` group — with
+name matches ranked above description matches.
+
+```console
+$ holocron
+? What would you like to do? › repo
+❯ repo ›
+? repo — choose a subcommand: › upgrade
+? repo upgrade — choose a subcommand: › node
+? Target Node.js major version: › 24
+```
 
+For a command that declares options (so far: `package publish` — more are
+rolled out one command group at a time), it also offers those: any required
+option is prompted like a positional, and everything else goes through one
+"Set any options?" checkbox, prompting only what you picked:
+
+```console
+? Set any options? (space to select, enter to skip) › ◉ npm dist-tag ◯ One-time password (2FA)
+? npm dist-tag (blank = latest): › beta
 ```
-$ holocron
-? What would you like to do? › dep
-────────────────────────────────────────────────
-❯ deploy   Trigger a deployment via the configured `deployment` capability
 
-? Branch to deploy: › main
+`package publish` specifically has three workflows that don't mix — a
+steady-state publish, a one-shot `--initial` bootstrap, and a `--sync-trust`
+maintenance run — so it asks which one first, then only offers that
+workflow's own options; nothing from a different workflow is ever shown:
+
+```console
+? What would you like to do? › Initial publish (--initial)
+? Set any options? (space to select, enter to skip) › ◉ One-time password (2FA)
+...dry-run output...
+? Dry run complete — proceed with the real run? › yes
+? One-time password (2FA), if npm requires it for this publish: › ***
 ```
 
+Each workflow's label ends with its real flag in parentheses when it has
+one, and a longer caveat ("use only for a package's very first publish")
+shows as helper text under the highlighted choice rather than bloating the
+label itself.
+
+A secret option (`--otp`) is masked as you type and delivered to the spawned
+command through its environment, never its argv — `ps` and shell history
+both expose a child's argv, never its env. A time-sensitive one like `--otp`
+is checked off early but not actually typed until right before the real run
+— after the dry-run preview and the "proceed?" question, never before —
+since a dry run never checks it anyway and a code typed any earlier risks
+going stale while something else is still being answered.
+
+Whether an option is _checkbox-optional vs. always included_ and _collected
+upfront vs. collected last_ are independent choices. `package publish`'s
+`--otp` is always collected last, but whether it's checkbox-optional depends
+on `HOLOCRON_NPM_ENFORCE_2FA`: unset (the default), it's opt-in like any other
+checkbox pick; set in your own shell profile (never checked into the repo),
+it's always included — for an operator whose own npm account enforces 2FA
+on every publish, so the box doesn't need re-checking every single run.
+Setting it has no effect on anyone else publishing from the same repo.
+
 The picked command spawns as a normal `holocron <command> …` invocation —
 `--token`, `--org`, `--cwd`, and `--dry-run` on the original invocation carry
 through. A non-interactive shell (CI, a script, a pipe) gets the old
 hard-failure message instead of hanging on a prompt.
 
+For a command whose handler honours `--dry-run` (most of them — everything
+except `auth *` and `config show`), the menu always previews it first — a
+dry run doesn't mutate anything, so there's nothing to ask permission for —
+then asks the one real decision:
+
+```console
+...dry-run output...
+? Dry run complete — proceed with the real run? › yes
+```
+
+A preview that reports nothing would actually change (e.g. `clone` finding
+every repo already cloned) skips that question too — there'd be nothing for
+the real run to do either. `--skip-dry-run` opts out of the preview
+entirely, straight to the real run, for when you already know what you want.
+
 ## Execution contexts
 
 Every command is tagged with how much of a repo it needs:
 
-| Context      | Needs                                                    | Examples                                                                                     |
-| ------------ | -------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
-| `global`     | just the CLI binary                                      | `version`, `clone`, `new`, `upgrade node`, `auth set` / `check`, `plugin create`, `skills …` |
-| `repo-aware` | `./holocron.config` in cwd, no plugins                   | `run`, `ci`, `config show`, `sync-readme`                                                    |
-| `workspace`  | the `@theholocron/holocron-plugin-*` packages resolvable | `doctor`, `setup`, `sync`, `secrets sync`, `deploy`                                          |
+| Context      | Needs                                                    | Examples                                                                                                                          |
+| ------------ | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
+| `global`     | the CLI binary alone                                     | `version`, `clone`, `new repo` / `plugin`, `repo upgrade …`, `auth set` / `check`, `package …`, `run lint commit-msg`, `skills …` |
+| `repo-aware` | `./holocron.config`, walking up from cwd, no plugins     | `run`, `run ci`, `config show`, `repo sync readme`, `deploy on-release`                                                           |
+| `workspace`  | the `@theholocron/holocron-plugin-*` packages resolvable | `doctor`, `repo setup`, `repo sync`, `secrets …`, `deploy`, `sync github`                                                         |
 
 A `workspace` command run from a bare global install (no plugins next to the
 CLI) fails with one actionable line — install the plugins as devDependencies or
@@ -51,6 +119,21 @@ use `pnpm exec holocron <cmd>`. `auth check` degrades to "token present,
 verification skipped" instead. `holocron --help` prints the grouping; see
 [Execution Contexts](https://theholocron.github.io/holocron/execution-contexts).
 
+### Viewing the resolved config
+
+`holocron config show` prints the resolved config. On a TTY it opens a foldable
+tree by default; piped or redirected, it always emits plain, valid JSON
+(`holocron config show | jq`).
+
+```console
+holocron config show                  # TTY: foldable tree (↑↓ move, →/⏎ expand, ← collapse, E/C all, q quit)
+holocron config show --depth 2        # static coloured tree, anything nested deeper than 2 levels collapsed
+holocron config show --no-interactive # static coloured tree, fully expanded
+```
+
+Passing `--interactive` explicitly needs a TTY on stdin and stdout and fails
+with a one-line message otherwise; the default falls back to static output. It has no extra dependencies — nothing to install.
+
 ## Config file
 
 Holocron reads `holocron.config.{json,js,ts}` from the project root
@@ -103,18 +186,18 @@ A minimal config — for repos with a `package.json` and a GitHub remote
 
 ### repo options
 
-Additional `repo` fields recognised by `holocron setup`:
+Additional `repo` fields recognised by `holocron repo setup`:
 
-| Field             | Type                                    | Description                                                                                                                                                                |
-| ----------------- | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `repo.teams`      | `Array<string \| { slug, permission }>` | GitHub teams granted repo access. String shorthand defaults to `push` (Write). `holocron setup` also writes `.github/CODEOWNERS` for teams with `push`/`maintain`/`admin`. |
-| `repo.topics`     | `string[]`                              | GitHub topics set on the repository.                                                                                                                                       |
-| `repo.protection` | `"balanced" \| "strict" \| "none"`      | Branch-protection preset applied by `holocron setup`. For `"strict"`, the required status checks are derived from the task manifest — see below.                           |
-| `repo.properties` | `RepoProperties`                        | Org-level custom property values synced to the GitHub dashboard.                                                                                                           |
+| Field             | Type                                    | Description                                                                                                                                                                     |
+| ----------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `repo.teams`      | `Array<string \| { slug, permission }>` | GitHub teams granted repo access. String shorthand defaults to `push` (Write). `holocron repo setup` also writes `.github/CODEOWNERS` for teams with `push`/`maintain`/`admin`. |
+| `repo.topics`     | `string[]`                              | GitHub topics set on the repository.                                                                                                                                            |
+| `repo.protection` | `"balanced" \| "strict" \| "none"`      | Branch-protection preset applied by `holocron repo setup`. For `"strict"`, the required status checks are derived from the task manifest — see below.                           |
+| `repo.properties` | `RepoProperties`                        | Org-level custom property values synced to the GitHub dashboard.                                                                                                                |
 
 ### Custom properties synced to GitHub
 
-`holocron setup` and `holocron sync` both call `syncProperties()` with two
+`holocron repo setup` and `holocron repo sync` both call `syncProperties()` with two
 kinds of fields — always one-way (`holocron.config.ts` → resolved →
 properties; properties are never a second editable source of truth):
 
@@ -160,7 +243,7 @@ posts, instead of reporting pass/fail.
 
 ### Required status checks (`protection: "strict"`)
 
-`holocron setup` builds the branch-protection required-check list from the
+`holocron repo setup` builds the branch-protection required-check list from the
 manifest, not a hand-maintained array:
 
 - `"DCO"` (hard-prepended), then
@@ -186,12 +269,32 @@ The generated ruleset also sets `require_extra_approval_for_unattributed_changes
 false` — with `required_approving_review_count: 0` and a single maintainer, the
 GitHub default (`true`) is an unsatisfiable block on any PR with an
 unverified/unattributed commit. Repository-admin bypass still covers the real
-risk. And the `codecov.yml` `holocron setup` writes carries `if_not_found:
+risk. And the `codecov.yml` `holocron repo setup` writes carries `if_not_found:
 success` on every status default, so an infra-only PR (dep bump, config,
 lockfile — no coverable change) passes instead of hanging on a `codecov/*`
-required check that never posts. A re-run of `holocron setup` backfills both into
+required check that never posts. A re-run of `holocron repo setup` backfills both into
 an existing repo.
 
+### Default branch (`repo.defaultBranch`)
+
+```ts
+export default defineConfig({
+  repo: { protection: "strict", defaultBranch: "alpha" },
+  providers: { source: "github" },
+});
+```
+
+`holocron repo setup` syncs GitHub's repo-level default branch (`HEAD`) — what a
+fresh clone checks out, what `gh pr create`/the compare UI target by default,
+and what Sentinel's `validateConfig()` reads (it only ever reads config from
+the repo's default branch, never a PR ref — a deliberate security boundary).
+Omit this field to leave GitHub's current setting untouched; most repos never
+need it. It exists for a repo using a `main`/`alpha` prerelease-channel split
+where active development happens on a non-`main` branch: set this to that
+branch so Sentinel validates against what's actually being developed, then
+change it back once that branch merges to `main` for a stable cut and stops
+being the active branch.
+
 ### Git hooks
 
 ```ts
@@ -202,7 +305,7 @@ export default defineConfig({
 });
 ```
 
-`holocron setup` writes `.husky/pre-push` (runs `holocron ci` before every
+`holocron repo setup` writes `.husky/pre-push` (runs `holocron run ci` before every
 push) and `.husky/pre-commit` (runs `gitleaks protect --staged` + `lint-staged`
 before every commit — scoped to staged changes, not the whole history, so a
 past false positive can't permanently block future commits) and sets
@@ -213,7 +316,7 @@ setup --hooks` / `--no-hooks` override per run. Bypass one push with `git push
 
 ### Task scripts
 
-`holocron sync` reconciles `package.json#scripts` from the `tasks` manifest
+`holocron repo sync` reconciles `package.json#scripts` from the `tasks` manifest
 (merge, never clobber — only the managed keys are touched):
 
 ```ts
@@ -248,8 +351,8 @@ export default defineConfig({
 `@theholocron/astromech`'s `loadTasksConfig` merges it over
 `holocron.config`'s `tasks` — **task arrays concatenate**
 (`holocron.config` first), the dedicated file **wins on scalars**,
-`extraRequiredChecks` concatenate. `holocron run` / `holocron ci` /
-`holocron setup` / `holocron sync` all read the merged result, so the
+`extraRequiredChecks` concatenate. `holocron run` / `holocron run ci` /
+`holocron repo setup` / `holocron repo sync` all read the merged result, so the
 split is transparent. Useful for keeping the capability/provider config
 and the "what this repo runs" manifest in separate files (this repo does).
 
@@ -276,10 +379,27 @@ job execute the same thing — at a turbo root both are
 `turbo run test -- --coverage` (the registry's org-default flags flow through
 turbo's `--`).
 
-### `holocron ci`
+### `holocron deploy on-release`
 
 ```bash
-holocron ci [--all] [--filter <pkg>] [--dry-run]
+holocron deploy on-release [--channel <alpha|main>] [--from <commit>] [--to <commit>] [--dry-run]
+```
+
+Deploys every workspace package whose own `holocron.config` declares
+`{ name: "delivery.deploy", with: { on: "release" } }` (holocron#930), when the
+release (`--channel`: its prerelease identifier, or `main`/empty for a stable
+release) is on the task's `channel` (default `main`, the stable release) and changes the package or one of its
+`workspace:*` dependencies between `--from` (the previous release's commit,
+omitted when there is none) and `--to` (default `HEAD`). It waits for npm to
+serve the release's new dependency versions, then runs `pnpm --filter <pkg>
+delivery.deploy`. A package that doesn't apply is skipped; a deploy that
+doesn't succeed exits non-zero. The shared `delivery.publish` workflow runs it as its own
+`deploy` job after the release job (opt in with `deploy-on-release: true`).
+
+### `holocron run ci`
+
+```bash
+holocron run ci [--all] [--filter <pkg>] [--dry-run]
 ```
 
 Runs the merge-gating checks locally, in CI order, exiting non-zero on the
@@ -293,6 +413,46 @@ Order comes from the `CI_ORDER` constant in `@theholocron/astromech`
 expands into its sub-jobs (each under its own `audit / …` check context)
 unless the repo ships its own `"audit"` script.
 
+### `holocron deploy`
+
+`holocron deploy <branch>` (a Git-linked deployment) and `holocron deploy
+--files <dir>` (a directory of build output, no linked repo) both trigger a
+deployment through the configured `deployment` capability, then **wait for
+it to finish**. The command reports success, exit code 0, only when the
+deployment reaches `ready`. A deployment that ends `error` or `cancelled`,
+or is still building after 10 minutes, is a failure: the exit code is
+non-zero and the output includes the provider's own reason
+(`DeploymentRecord.errorMessage`, e.g. Vercel's `Command "npm install"
+exited with 1`). Providers build asynchronously, so accepting a deployment
+isn't the same as it going live (holocron#911).
+
+Provider plugins support this through the `Deployment` capability's
+existing `getDeployment(id)`. They should set `errorMessage` on the
+returned `DeploymentRecord` whenever the provider exposes one.
+
+### `holocron monitoring check <url>`
+
+Runs every configured `monitoring` check against `<url>` instead of each
+check's own configured `url` — no vendor API call, only a plain HTTP
+request evaluated locally against the exact same `assertions` already in
+`holocron.config.ts`. Built for CI: the `delivery.previewCheck` task runs
+this against a PR's Vercel preview deployment (triggered by
+`deployment_status`, not `push`/`pull_request`), reusing the production
+check definitions to catch a breaking change before merge instead of
+after (holocron#1010).
+
+```ts
+export default defineConfig({
+  tasks: ["delivery.previewCheck"],
+  providers: {
+    monitoring: ["checkly", { accountId: "...", checks: [/* ... */] }],
+  },
+});
+```
+
+Exits non-zero if any check fails — the job's own pass/fail is what
+posts as the GitHub check, no separate reporting step needed.
+
 ### Lint parity
 
 The `lint` task takes an optional `linters` array — one list that drives
@@ -310,7 +470,7 @@ export default defineConfig({
 
 ### Skills installer
 
-`holocron setup` can install shared skills from `@theholocron/skills` into the local repo:
+`holocron repo setup` can install shared skills from `@theholocron/skills` into the local repo:
 
 ```ts
 export default defineConfig({
@@ -371,18 +531,62 @@ export default acmeConfig;
 
 ```
 
+## Notifications — server as code
+
+A `notifications` provider can declare a whole server in `holocron.config.ts`
+(`layout`: categories, channels, roles, access, server settings, welcome screen,
+onboarding, the bot application) and the CLI applies and checks it. The
+commands and the config are provider-neutral; Discord is the first provider.
+
+| Command                                        | What it does                                                                                                           |
+| ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| `holocron notifications setup`                 | Applies the layout; looks everything up by name first, so a re-run changes nothing that matches                        |
+| `holocron notifications channel add <name>`    | Creates one channel (optionally with a webhook whose URL is stored as a secret)                                        |
+| `holocron notifications link`                  | Links your account on the provider to your GitHub account by signing in with the provider (OAuth, nothing secret kept) |
+| `holocron notifications sync-roles`            | Makes who holds a role match a GitHub team, through the links file (`--keep` only adds; `--provider` picks one)        |
+| `holocron doctor notifications [--built-only]` | Read-only, step by step: does the server match the layout, and do the secrets exist                                    |
+
+Config shape added for role sync and sign-in (all under the provider's `layout`):
+
+| Field                         | Meaning                                                                                                                                                     |
+| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `roles[].team`                | A GitHub team slug. The role follows that team: given to linked members, taken from linked people who left. Never touches holders nobody has linked.        |
+| `links.hostedUrl`             | A hosted sign-in service (Sentinel). `link` asks `<hostedUrl>/api/link` and uses it when it answers `{ "service": "link" }`; otherwise it signs in locally. |
+| `links.localPort`             | The port of the local sign-in listener (default `53682`, bound to `127.0.0.1` only).                                                                        |
+| `links.repo` / `links.path`   | Where the links file lives (default `<org>/.github-private` and `notifications/<provider>-links.json`).                                                     |
+| `application.intents.members` | Switches the Server Members Intent on or off (needed to list who holds a role).                                                                             |
+| `application.redirectUris`    | Redirect URIs that must be registered. Check-only: the API cannot set them, so `setup` and the doctor say what to add in the developer portal.              |
+
+The links file is `{ "version": 1, "links": [{ "github": "<id>", "login": "<login>", "member": "<id>" }] }`: two public ids per person.
+It is read and written through the `source` capability with the `github.user-sync` token (fine-grained, **only** the
+private config repo, Contents read and write), so no other token needs Contents on other repositories.
+
+Capability surface behind it (all optional, so providers without the concept omit them):
+
+- `Source.teamMembers(teamSlug, org?)`, `Source.readFile(path, repo?)` (returns the `version` a later write must present),
+  `Source.writeFile(path, content, { message, version?, repo? })` (a changed `version` is refused: a real conflict check).
+- `Notifications.roleMembers(role)`, `addRoleMember(role, memberId)`, `removeRoleMember(role, memberId)`.
+- `Notifications.signIn()` returning `{ authorizeUrl, complete }`: the provider-neutral shape of "prove which account you own".
+- `Notifications.ensureApplication` returns `{ updated, todo? }`; each `todo` is a step only a person can do (a portal setting
+  the API ignores) and is reported as a failure until done.
+
+Provider credentials for Discord: `discord.holonet` is the **bot token** (Bot → Reset Token), `discord.holonet.oauth` is the
+**OAuth client secret** (OAuth2 → Reset Secret). They are different values; the API can create or read neither.
+
+See the [command pages](https://theholocron.dev/holocron/commands/notifications-setup/) for each command's options.
+
 ## Upgrading
 
-- **`holocron upgrade node <to>`** — patches every Node.js version pin
+- **`holocron repo upgrade node <to>`** — patches every Node.js version pin
   (`engines.node`, `.nvmrc`, `.node-version`, `.github/workflows/*`,
   `Dockerfile`, `.tool-versions`) to a new major.
-- **`holocron upgrade deps`** — bumps every `@theholocron/*` pin in
+- **`holocron repo upgrade deps`** — bumps every `@theholocron/*` pin in
   `pnpm-workspace.yaml` (`catalog:` and every named `catalogs.*`) to its latest
   published version, then migrates `holocron.config.ts` from the 7.x preset
   shape (`const { repo, workflows } = node()` + `repo.requiredChecks` +
   `workflows:`) to the current composed-preset API (`const preset = node()` +
   `...preset` + `tasks:` + `extraRequiredChecks:`). Mechanical transforms only —
-  review the result, then `pnpm install && holocron ci`. `--pins-only` skips
+  review the result, then `pnpm install && holocron run ci`. `--pins-only` skips
   the config migration; `--dry-run` prints without writing.
 
 ## Auth — fine-grained tokens
@@ -397,11 +601,12 @@ holocron auth set github.issues   ghp_xxx  # issue management
 holocron auth set github.sync     ghp_xxx  # sync-github workflow templates
 holocron auth set github.release  ghp_xxx  # semantic-release
 holocron auth set github.admin    ghp_xxx  # setup, secrets, environments
+holocron auth set github.user-sync ghp_xxx # the files that link GitHub accounts to other services' members
 ```
 
 The resolution chain per capability is:
 
-```
+```text
 --token flag → HOLOCRON_<FEATURE>_TOKEN env var → keyring("github.<feature>")
 ```
 
@@ -418,16 +623,21 @@ holocron auth list                # show all stored providers
 ## Logging
 
 Operational output goes through `@theholocron/observability/logger` — separate
-from the user-facing `print` surface. Global flags:
+from the user-facing `print` surface. Local/interactive runs are quiet by
+default: no colorized or raw structured console output, regardless of the
+resolved level (Axiom shipping, when configured, is unaffected). CI is
+untouched — its existing stdout output still appears. Global flags:
 
 ```sh
-holocron doctor --verbose   # log level → debug (full structured output)
-holocron doctor --quiet     # log level → error (suppress info + warn)
+holocron doctor --log debug # show console output at this level (opt back in)
+holocron doctor --verbose   # log level → debug, and shows console output
+holocron doctor --quiet     # log level → error, and shows console output
 holocron doctor --debug     # print "Run ID: <uuid>" at command end for Axiom lookup
 ```
 
-Level resolution (highest priority first): `--verbose` / `--quiet` →
-`HOLOCRON_LOG_LEVEL` → `log.level` in `holocron.config` → `"info"`.
+Level resolution (highest priority first): `--log <level>` → `--verbose` /
+`--quiet` → `HOLOCRON_LOG_LEVEL` → `log.level` in `holocron.config` →
+`"info"`.
 
 ```ts
 export default defineConfig({
@@ -439,7 +649,16 @@ Axiom shipping activates when a token (`HOLOCRON_AXIOM_TOKEN` / `AXIOM_TOKEN`
 → OS keyring `axiom.<org>` → `axiom`) **and** a dataset
 (`HOLOCRON_AXIOM_DATASET` / `AXIOM_DATASET` → `log.axiom.dataset` in
 `holocron.config`) both resolve; env vars win. The token is never read from a
-config file. See the [logging guide](https://docs.theholocron.dev/holocron/logging/).
+config file.
+
+The dataset side of that resolution is **execution-context-aware** (ADR-0012):
+a `global`-context command (`clone`, `new`, `auth set`, `upgrade node`, `plugin
+create`, …) always ships to holocron's own dataset regardless of `$PWD` — it
+isn't "about" any repo, so routing it through whichever repo's `.envrc`
+happens to be active would be wrong. `repo-aware` / `workspace` commands
+(`doctor`, `deploy`, `sync`, …) keep the env-var/config chain above, so a
+per-repo `HOLOCRON_AXIOM_DATASET` — e.g. via a `.envrc` + `direnv` — separates
+each consuming repo's logs. See the [logging guide](https://docs.theholocron.dev/holocron/logging/).
 
 ### Telemetry
 
@@ -468,38 +687,69 @@ export default defineConfig({
 
 Each SDK sits behind an interface from `@theholocron/observability` —
 `ErrorSink` (Sentry) / `AnalyticsSink` (PostHog); the adapters, and the only
-`@sentry/node` / `posthog-node` imports, live in that package. `telemetry.ts`
+`@sentry/node` / `posthog-node` imports, live in that package. `observability/telemetry.ts`
 holds the orchestration + the Holocron-specific credential resolution
-(`telemetry/resolve.ts`). See the
+(`observability/resolve-telemetry.ts`). See the
 [telemetry guide](https://docs.theholocron.dev/holocron/telemetry/).
 
+### ESLint bundle options
+
+Most repos need nothing here — `@theholocron/eslint-config`'s `library()`
+bundle resolves with zero committed file (Bucket A: `eslint --config
+<shared path>`, no per-repo `eslint.config.ts` needed). A package with a
+genuine, deliberate exception — e.g. Web Crypto globals a Node-targeted
+package still needs, exempted via `library()`'s own `browserPackages`
+option in that package's own `eslint.config.ts` — should also declare the
+same paths in `holocron.config`'s `eslint.browserPackages`:
+
+```ts
+export default defineConfig({
+  eslint: {
+    browserPackages: ["packages/github-client/src/app-auth"],
+  },
+});
+```
+
+This doesn't replace the package's own `eslint.config.ts` (local/CI linting
+still resolves that file directly) — it's the signal Sentinel's centralized
+static-analysis check (holocron#849/#858) reads instead, since that check
+never reads a PR's own committed config files. Without it, Sentinel flags a
+false-positive `eslint-plugin-n` node-builtins finding on exactly the files
+the local override exists to exempt.
+
 ## What's in here
 
-- `src/capabilities/` — the 14 capability interfaces that providers
-  implement
+- `src/plugin/capabilities.ts` — the 18 capability interfaces that
+  providers implement
 - `src/config.ts` — config schema, `defineConfig`, `resolveConfig`,
   `CapabilityConfigPackage`
 - `src/config/load-config.ts` — `loadConfig` — reads `holocron.config.*`
   (file discovery via [`@theholocron/datapad`](../datapad))
 - `src/define-config.ts` — `defineConfig` typed pass-through
-- `src/logger.ts` — CLI-side `@theholocron/observability/logger` wiring
+- `src/observability/logger.ts` — CLI-side `@theholocron/observability/logger` wiring
   (`buildCliLogger`, `resolveLogLevel`)
 - `src/loader.ts` — `PluginLoader` — dynamic-imports plugins, resolves
   capability config packages, builds the capability registry
 - `src/cli.ts` — yargs entry, dispatches subcommands. `holocron run` / `ci` are
   delegated to [`@theholocron/astromech`](../astromech) (`createAstromech`).
-  `holocron sync` / `holocron setup` write each repo's `.github/workflows/*.yml`
-  thin callers from `astromech.thinCallers()`; `holocron sync-github` pushes the
+  `holocron repo sync` / `holocron repo setup` write each repo's `.github/workflows/*.yml`
+  thin callers from `astromech.thinCallers()`; `holocron sync github` pushes the
   reusable `workflow_call` implementations + composite actions from
   `astromech.reusableTemplates()` to `theholocron/.github` (a pure sync target —
   never hand-edit its `.github/workflows/*`).
-- `src/commands/` — `setup`, `sync`, `doctor`, `deploy`, `secret set`,
-  `secrets sync`, `publish`, `bump-versions`, `sync-github`, `upgrade node`,
-  `upgrade deps`, `plugin create`, `auth`
-- `src/interactive-menu.ts` — the interactive fallback: `COMMAND_REGISTRY`,
-  `launchMenu` (Layers 1–2, picks + spawns a fresh `holocron <command>`),
-  `promptForPositionals` (Layer 3, called inline from each leaf command's
-  `cli.ts` handler)
+- `src/commands/` — `repo setup`, `repo sync`, `doctor`, `deploy`,
+  `monitoring check`, `secrets set`, `secrets sync`, `package publish`,
+  `package bump-versions`, `sync github`, `repo upgrade node`,
+  `repo upgrade deps`, `new plugin`, `auth`, `notifications setup`,
+  `notifications channel add`, `notifications link`,
+  `notifications sync-roles`, `doctor notifications`
+- `src/interactive-menu/` — the interactive fallback: `command-registry`
+  (`COMMAND_REGISTRY`, each entry's `positionals`/`options`), `launch-menu`
+  (Layers 1–2, picks + spawns a fresh `holocron <command>`), `child-argv`
+  (builds the spawned argv + secret env), `menu-items`, `run-menu-entries`.
+  The generic prompting pieces it calls — `promptForPositionals`,
+  `promptForOptions` (Layer 3) — live in `src/ui/`, which has no knowledge
+  of commands.
 
 ## Status