@hublo/sentinel 1.5.1-alpha.2 → 1.6.0-alpha.0

package/dist/index.d.ts

@@ -32,11 +32,31 @@ declare function registerAdapters(): void;
 declare const VERBS: readonly ["run", "inspect", "init", "migrate", "validate", "report", "status"];
 type Verb = (typeof VERBS)[number];
 /** Targets: the kind of check. The CLI `--<target>` flags map 1:1 to these. */
-declare const TARGETS: readonly ["lint", "format", "typescript", "build", "dev", "test", "static-analysis", "runtime-analysis", "arch"];
+declare const TARGETS: readonly ["lint", "format", "typescript", "build", "dev", "test", "static-analysis", "env", "runtime-analysis", "arch"];
 type Target = (typeof TARGETS)[number];
 /** Presets: the stack preset a project resolves to (strict by default). */
 declare const PRESET_NAMES: readonly ["react", "nest", "svelte", "node", "tools"];
 type PresetName = (typeof PRESET_NAMES)[number];
+/**
+ * What the env role does with what it finds, from `SENTINEL_ENV_LEVEL`.
+ *
+ * | level | reports | in GitHub Actions | exit |
+ * | --- | --- | --- | --- |
+ * | `info` | yes | nothing more | 0 |
+ * | `warning`, the default | yes | a `::warning` annotation per finding | 0 |
+ * | `error` | yes | `::error` on a blocking finding, `::warning` on the rest | 1 on a blocking finding |
+ *
+ * An environment variable and not a flag, because the same command runs in a developer's shell and
+ * in every repository's CI, and what changes between them is the policy, not the command: a team
+ * moves from `warning` to `error` by setting one variable in its workflow, without editing the step.
+ *
+ * ⛔ Here and not in the role for the reason `OUTPUT_SHAPES` is: it is read and VALIDATED at the CLI
+ * edge, once, before any role runs, and handed to the role as data. A role that read the
+ * environment itself would be the one place in this package whose behaviour a test cannot pin by
+ * its inputs.
+ */
+declare const ENV_LEVELS: readonly ["info", "warning", "error"];
+type EnvLevel = (typeof ENV_LEVELS)[number];
 /**
  * @deprecated Renamed to `PresetName`. Kept so an existing `import type { Flavour }` keeps
  * compiling: the CLI kept `--flavour` working for the same reason, and breaking the type
@@ -120,6 +140,16 @@ interface RunContext {
      * The role rejects a shape it does not know, by name.
      */
     output?: string;
+    /**
+     * `SENTINEL_ENV_LEVEL`, validated by the CLI. Read by the env role only, and only through here:
+     * the role never reads the environment, so a test pins its behaviour by passing a value.
+     */
+    envLevel?: EnvLevel;
+    /**
+     * Whether the run is inside GitHub Actions (`GITHUB_ACTIONS=true`), read once by the CLI for the
+     * same reason as `envLevel`. A role that can annotate a pull request does so only when this is set.
+     */
+    githubActions?: boolean;
 }
 /**
  * A single, DECLARATIVE file operation an `--init` wants to happen. Adapters

package/dist/index.js

@@ -6,12 +6,13 @@ import {
   registerAdapters,
   resolve,
   setDefaultRunner
-} from "./chunk-JHLNNIZC.js";
+} from "./chunk-PC5R4DX5.js";
 import {
   BaseAdapter
 } from "./chunk-P7NYSMLS.js";
 import "./chunk-JRZI5IIN.js";
-import "./chunk-WBDBRGLV.js";
+import "./chunk-7E6YTTAK.js";
+import "./chunk-NAFI7OLI.js";
 import "./chunk-O7REVMOC.js";
 import "./chunk-QXFCZON7.js";
 export {

package/dist/roles/env/config.d.ts

@@ -0,0 +1,90 @@
+/**
+ * `defineEnv`: what a repository writes to declare its own env facts, all of them optional.
+ *
+ * ```js
+ * // env.config.mjs, at the repository root
+ * import { defineEnv } from '@hublo/sentinel/env'
+ *
+ * export default defineEnv({
+ *   externallyProvided: ['NODE_ENV'],
+ *   allowNonBlankedSecrets: ['apps/front/x/.env.example:LEGACY_API_KEY'],
+ * })
+ * ```
+ *
+ * A repository that does not install sentinel, and runs it with `npx`, cannot import this module:
+ * its own `node_modules` has no `@hublo/sentinel`. So the file may export the same object PLAIN,
+ * and the role passes it through this function itself. Both spellings mean the same thing, and the
+ * function exists for the one that can import it: it validates at the moment the file is written,
+ * in an editor that knows the types.
+ *
+ * ## What a repository declares, and what stays sentinel's
+ *
+ * A repository declares FACTS about itself: which variables its CI injects, which committed value
+ * was reviewed and is not a secret, which Dockerfile must run as root, where its code lives. It
+ * does not redefine what a secret NAME looks like or how code reads env, which are the same in
+ * every repository and ship in `presets/shared.json`.
+ *
+ * Two semantics, stated once:
+ *
+ *  - `readers`, `envFiles` and `contracts` ADD to what sentinel ships, so no repository loses
+ *    `getOrFail` or `**\/.env` by declaring a reader or a glob of its own;
+ *  - `scan` and `references` REPLACE, key by key: a repository naming its `roots` says where its
+ *    code is, and keeping `.` beside them would scan everything anyway.
+ *
+ * ⛔ An unknown key is refused, by name. The file is `.mjs`, so nothing type-checks it, and a key
+ * spelled `allowNonBlankedSecret` would otherwise be ignored in silence while the finding it was
+ * meant to downgrade kept failing the build.
+ */
+/** A source scope a repository may narrow, every key optional. */
+interface EnvScopeInput {
+    roots?: string[];
+    ext?: string[];
+    excludeSuffixes?: string[];
+    excludeDirs?: string[];
+}
+/** What `env.config.mjs` exports. */
+interface EnvInput {
+    /** Required variables in no contract because CI injects them or a secret store provides them. */
+    externallyProvided?: string[];
+    /** Declared variables consumed outside scannable source, so never reported dead (rule 4). */
+    knownExternalVars?: string[];
+    /** The same, by pattern, for a whole category such as `/_DATABASE_URL$/`. */
+    knownExternalPatterns?: (RegExp | string)[];
+    /** `<file>:<VAR>` locations whose committed value was reviewed and is not a secret (rule 6). */
+    allowNonBlankedSecrets?: string[];
+    /** Committed real env files permitted anyway, such as a test fixture (rule 2). */
+    allowedCommittedEnvFiles?: string[];
+    /** Globs of env files to read, ADDED to `**\/.env`, `**\/.env.*` and `**\/*.env`. */
+    envFiles?: string[];
+    /** Globs of contracts, ADDED to `**\/*.env*.example`. */
+    contracts?: string[];
+    /** Where the named readers are looked for (rules 1 and 3). Replaces, key by key. */
+    scan?: EnvScopeInput;
+    /** Where direct `process.env` reads are looked for (rules 3 and 4). Replaces, key by key. */
+    references?: EnvScopeInput;
+    /** Reader names ADDED to sentinel's: `required` throw when absent, `optional` default. */
+    readers?: {
+        required?: string[];
+        optional?: string[];
+    };
+    /** Docker rules: Dockerfiles allowed to run as root, and path prefixes not checked at all. */
+    docker?: {
+        allowRoot?: string[];
+        excludePaths?: string[];
+    };
+}
+/**
+ * Validate a repository's env declaration and return it unchanged.
+ *
+ * The defaults are NOT merged in here. They ship with sentinel and are applied when the role runs,
+ * so changing one reaches every repository at its next sentinel version instead of leaving a copy
+ * frozen in each config. That also makes this function idempotent, which is what lets the role
+ * pass a plain exported object through it a second time.
+ *
+ * @param input the declaration; omitted, the repository declares nothing
+ * @returns the same declaration
+ * @throws naming every unknown key and every malformed value at once
+ */
+declare function defineEnv(input?: EnvInput): EnvInput;
+
+export { type EnvInput, type EnvScopeInput, defineEnv };

package/dist/roles/env/config.js

@@ -0,0 +1,7 @@
+import {
+  defineEnv
+} from "../../chunk-NAFI7OLI.js";
+export {
+  defineEnv
+};
+//# sourceMappingURL=config.js.map

package/dist/roles/env/config.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":[],"sourcesContent":[],"mappings":"","names":[]}

package/dist/roles/static-analysis/config.js

@@ -1,6 +1,6 @@
 import {
   defineStaticAnalysis
-} from "../../chunk-WBDBRGLV.js";
+} from "../../chunk-7E6YTTAK.js";
 export {
   defineStaticAnalysis
 };

package/dist/roles/test/setup/jest-parity.js

@@ -1,3 +1,7 @@
+import {
+  clearDeepMocks,
+  resetDeepMocks
+} from "../../../chunk-2XLX6PFR.js";
 import {
   alreadyInstalled
 } from "../../../chunk-NUOQXAYR.js";
@@ -5,10 +9,6 @@ import {
   installWorkspaceSetup
 } from "../../../chunk-LFNOBQZU.js";
 import "../../../chunk-ELZHIN6E.js";
-import {
-  clearDeepMocks,
-  resetDeepMocks
-} from "../../../chunk-2XLX6PFR.js";
 import "../../../chunk-JRZI5IIN.js";
 
 // src/roles/test/setup/jest-parity.ts

package/docs/env-adoption.md

@@ -0,0 +1,229 @@
+# Env conformance cheat sheet
+
+The `env` role checks a **repository**, not a module: which env files git tracks, whether the code
+reads a variable no contract declares, whether a secret-named variable carries a committed value,
+and whether the Dockerfiles copy paths that exist and drop root at runtime. It is the monorepo's
+`tools/repo-env` (`validate`, `docker-check`, `inventory` and `ci-gate`) made to run on any
+repository, including one that is not an nx workspace.
+
+```bash
+# from the repository ROOT (the git top-level), nothing to install
+npx --yes @hublo/sentinel@<version> --run --env
+```
+
+It writes no config, so there is no `--init`. With no `env.config.mjs` it runs on sentinel's
+defaults, and says so in its header.
+
+## The level: `SENTINEL_ENV_LEVEL`
+
+The same findings are reported at every level. The level decides what they DO.
+
+| `SENTINEL_ENV_LEVEL` | reports | in GitHub Actions (`GITHUB_ACTIONS=true`)                   | exit                        |
+| -------------------- | ------- | ----------------------------------------------------------- | --------------------------- |
+| `info`               | yes     | nothing more                                                | 0                           |
+| `warning` (default)  | yes     | one `::warning file=…,line=…::` annotation per finding      | 0                           |
+| `error`              | yes     | `::error` on a blocking finding, `::warning` on an advisory | **1** on a blocking finding |
+
+An unknown value is refused with exit 1 rather than read as the default: a typo of `error` that ran
+as `warning` would turn a gate into a report, and nobody would see it stop gating.
+
+⚠️ It is refused like an unknown option: before ANY role runs. A bare `sentinel --run` at the
+repository root includes `env`, so an invalid `SENTINEL_ENV_LEVEL` there refuses the whole sweep,
+lint, format, typescript, build and test included, not only `env`. The variable is read only when
+`env` is part of the run: `sentinel --run --lint`, a bare `--run` from a module below the root, and
+every other verb never read it, so it cannot refuse them.
+
+Under `--json` the annotations go to **stderr**, so stdout stays one JSON document; the runner
+reads workflow commands from both streams.
+
+## The rules
+
+| #   | finding id                                   | what it reports                                                                         | severity                                  |
+| --- | -------------------------------------------- | --------------------------------------------------------------------------------------- | ----------------------------------------- |
+| 1   | `required-var-undeclared`                    | a variable a required reader (`getOrFail`, …) reads, declared in no contract            | blocking                                  |
+| 2   | `committed-env-file`                         | a real env file tracked by git (anything that is not an `.example` contract)            | blocking                                  |
+| 3   | `var-not-in-app-contract`                    | a variable an app reads, declared only in ANOTHER app's contract                        | advisory                                  |
+| 4   | `dead-var`                                   | a declared variable read nowhere in source                                              | advisory                                  |
+| 5   | `public-secret-to-review`                    | a public-prefixed (`VITE_`, `PUBLIC_`, `NEXT_PUBLIC_`, `REACT_APP_`) secret-named value | advisory                                  |
+| 6   | `secret-not-blanked`                         | a secret-named variable with a committed value, in a contract OR a real env file        | blocking (`secret-allowlisted`: advisory) |
+| 7   | `dead-copy-path`                             | a `COPY` source that does not exist                                                     | blocking                                  |
+| 8   | `nx-project-missing` / `nx-target-missing`   | an `nx run <project>:<target>` that does not exist                                      | blocking                                  |
+| 9   | `node-version-mismatch`                      | a `FROM node:<v>` that differs from `.node-version`                                     | blocking                                  |
+| 10  | `dockerfile-runs-as-root` / `copy-not-owned` | a runtime stage running as root, or a runtime `COPY` without `--chown`                  | blocking                                  |
+
+The blocking set is `repo-env ci-gate`'s, unchanged. Rules 3, 4 and 5 never block, at any level: a
+variable "read nowhere" can be read by a branch not merged yet, which is how the monorepo once
+deleted `VITE_CAREER_URL` from main while an open pull request read it.
+
+A finding carries a **file, a line, a variable name and a rule**. Never a value: there is no field
+a value could travel in, so no shape can print one.
+
+What the role cannot check, it says, in a `note:` line: no contract committed (rules 1, 3 and 4
+have nothing to compare with), no required reader call found (rule 1, naming the readers looked
+for, which `readers.required` extends), no `.node-version` (rule 9), no `nx.json` or an nx that cannot run
+(rule 8, with the count of references left unchecked).
+
+## Where it runs
+
+| from                                | `sentinel --run --env`                   | `sentinel --run` (sweep)                |
+| ----------------------------------- | ---------------------------------------- | --------------------------------------- |
+| the repository root (git top-level) | runs, once                               | includes `env` once, beside the modules |
+| a directory inside it (a module)    | **refused**, naming the root to run from | the module's roles only, as before      |
+| a directory in no git repository    | **refused**                              | the module's roles only, as before      |
+
+⛔ Inside a module it is refused, not scoped. Rule 3 compares one app's reads with another app's
+contract and rule 2's file may sit two directories up, so a scoped report is a smaller report that
+looks like a clean one. `--inspect`, `--init`, `--validate` and `--status` refuse `--env` and never
+sweep it: it has no config to read or write. `--module`, `--fix` and options after `--` are refused
+beside it.
+
+Discovery is `git ls-files`, never nx: a repository with no `nx.json` has no project graph to ask,
+and a filesystem walk would report a developer's untracked `.env` as committed. Rule 8 is the one
+place nx is used, the repository's OWN nx from its `node_modules`, and only when `nx.json` exists.
+
+## Output shapes
+
+| shape               | what                                                                                                                                                                         |
+| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| console (default)   | the report, grouped by rule with each rule's fix, then notes and the verdict                                                                                                 |
+| `--json`            | the engine envelope; the env row carries `level`, `verdict`, `blocking`, `findings`, `notes`, `counts` and the full `inventory` (required and optional variables, contracts) |
+| `--output json`     | the same document, written to `env-report/env.json`                                                                                                                          |
+| `--output markdown` | the pull-request recap, written to `env-report/env.md`, opening with `<!-- sentinel-env-report -->`                                                                          |
+
+`html` is not a shape this role writes, and asking it of `--env` alone is refused.
+
+## The repository's config: `env.config.mjs`
+
+Optional, at the repository root. A repository declares FACTS about itself; what a secret name
+looks like and how code reads env ship with sentinel.
+
+```js
+// env.config.mjs
+export default {
+  externallyProvided: ['NODE_ENV'], // required, but CI or a secret store provides it
+  knownExternalVars: ['CACHE_PATH'], // declared, consumed outside source (rule 4)
+  knownExternalPatterns: [/_DATABASE_URL$/], // the same, by category
+  allowNonBlankedSecrets: ['apps/x/.env.example:LEGACY_API_KEY'], // reviewed, not a secret (rule 6)
+  allowedCommittedEnvFiles: ['tests/fixtures/.env'], // rule 2
+  envFiles: ['**/*.envrc'], // ADDED to **/.env, **/.env.*, **/*.env
+  contracts: ['templates/*.env.dist'], // ADDED to **/*.env*.example
+  scan: { roots: ['apps', 'libs'] }, // where the named readers are looked for; replaces key by key
+  references: { roots: ['apps', 'libs'] }, // where direct process.env reads are looked for
+  readers: { required: ['mustGetEnv'] }, // ADDED to getOrFail, requireEnv, requireEnvVariable
+  docker: { allowRoot: ['images/legacy/Dockerfile'], excludePaths: ['local/'] },
+}
+```
+
+A repository that installs sentinel can write the same object through `defineEnv`, which an editor
+type-checks:
+
+```js
+import { defineEnv } from '@hublo/sentinel/env'
+export default defineEnv({ externallyProvided: ['NODE_ENV'] })
+```
+
+A repository that runs sentinel with `npx` cannot import it, since its own `node_modules` has no
+`@hublo/sentinel`; the plain object is the spelling for it, and the error says so if the import is
+tried. An unknown key is refused by name, in both spellings: the file is `.mjs`, and an ignored
+`allowNonBlankedSecret` would silently stop downgrading the finding it was written for.
+
+### Sentinel's defaults
+
+`presets/shared.json` in the role. Secret names match **case-insensitively** (`SECRET`, `TOKEN`,
+`PASSWORD`, `PRIVATE_?KEY`, `ACCESS_?KEY`, `API_?KEY`), so serviceapp's `facturationPassword` and a
+camel-case `apiKey` are seen. The scans read `.ts .tsx .mts .cts .js .jsx .mjs .cjs` (and `.svelte`,
+`.vue` for direct reads) across the whole repository, with test files left out of the reader scan.
+
+## In CI
+
+The role reads the plain checkout, so the step goes BEFORE anything that writes into the tree, a
+secret materialization or an env-file generation included:
+
+```yaml
+permissions:
+  contents: read
+  pull-requests: write
+steps:
+  - uses: actions/checkout@v4
+  - uses: actions/setup-node@v4
+    with:
+      node-version: 24.15.0
+  - run: npx --yes @hublo/sentinel@<version> --run --env --output markdown
+    env:
+      SENTINEL_ENV_LEVEL: warning
+  # then post env-report/env.md as a sticky comment, found by its first line
+```
+
+sentinel needs Node 24.15 to run, whatever Node the repository itself uses: `setup-node` here
+installs it for this step only.
+
+GitHub documents a cap of 10 warning and 10 error annotations per step
+(<https://docs.github.com/en/rest/checks/runs>): on a repository with more findings, the
+pull request shows only part of the annotations, and the markdown recap is the complete list.
+
+## What changed from `tools/repo-env`
+
+Measured by running both on the same monorepo commit, the monorepo's `repo-env.config.mjs`
+translated into an `env.config.mjs`: **51 of 52 findings identical**, plus every optional variable,
+and the one difference is intended (the first line below). Measured twice: on `origin/main` 3364bb9
+(97 optional variables) and again on 50c5157 on 30 October (102), after the COPY fix below, with
+the same single difference.
+
+| command of `tools/repo-env` | with sentinel                                                   |
+| --------------------------- | --------------------------------------------------------------- |
+| `validate`                  | `sentinel --run --env` (level `warning` or `info`: exit 0)      |
+| `docker-check`              | the same run: rules 7 to 10 are in every report                 |
+| `ci-gate`                   | `SENTINEL_ENV_LEVEL=error sentinel --run --env`                 |
+| `inventory`                 | `sentinel --run --env --json`, the row's `inventory`            |
+| `validate --app <name>`     | not ported: the role refuses a scoped run (see "Where it runs") |
+| `materialize`               | not ported, stays in the monorepo                               |
+
+- `Dockerfile.dockerignore` is no longer audited as an image running as root. A Dockerfile is read
+  from its NAME (`Dockerfile`, `Dockerfile.<x>`, `Dockerfile-<x>`, `<x>.Dockerfile`), never from a
+  `.dockerignore` or a `.md` that mentions one.
+- A lowercase or camel-case key is a key (`facturationPassword=` used to be skipped), and a
+  reference to one is seen, so it is not reported dead forever.
+- A bare `$VAR` in a `COPY` is a build argument, not a path that does not exist.
+- A `COPY` source is read the way Docker reads it: `COPY "entrypoint.sh" /app` checks
+  `entrypoint.sh`, the JSON form `COPY ["a", "b", "/app/"]` checks `a` and `b`, a heredoc checks
+  nothing. The original kept the quotes and reported servicecontract's `entrypoint.sh`, which sits
+  next to its Dockerfile, as a dead path, blocking.
+- A `v`-prefixed `.node-version` (`v10.15.3`) compares as a version; a missing one is a note, not
+  a crash.
+- Rule 6 reads every committed env file, not only contracts, and no contract at all is a note
+  rather than a refusal to run.
+- Every finding has a line, so an annotation lands on it.
+
+## Outside the monorepo: what `tools/repo-env` assumed, and what the port does
+
+`repo-env`'s README calls `repo-io.mjs` "mostly" repo-agnostic. These are the places where it, or
+its config, assumed the monorepo, and what the role does in a repository without nx and without
+that layout. Each line was RUN, from the packed tarball through `npx`, on six hublo repositories
+that are not the monorepo (serviceapp, serviceapi, servicecontract, servicemission, contract-front,
+servicebackoffice), on 30 October.
+
+| monorepo assumption                                                           | in the port                                         | outside the monorepo                                                                                                                                                    |
+| ----------------------------------------------------------------------------- | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| the root is the script's own `../..`                                          | the git top-level                                   | works, 6 of 6                                                                                                                                                           |
+| sources found by walking `apps/nest`, `libs/nest`, `apps/front`, `libs/front` | `git ls-files` under `.`                            | works, 6 of 6                                                                                                                                                           |
+| required reads are `getOrFail`, `requireEnv`, `requireEnvVariable`            | the same names, extendable with `readers`           | **degrades, said**: a repository reading `process.env.X` directly has no required read, so rule 1 has nothing to check, and a note says so, naming the readers (3 of 6) |
+| contracts are `*.env*.example`                                                | the same, extendable with `contracts`               | **degrades, said**: with none, rules 1, 3 and 4 are skipped with a note (serviceapp, servicebackoffice)                                                                 |
+| a real env file is `.env` or `.env.<x>`                                       | also `**/*.env`                                     | works: serviceapp's 9 `variables/*.variables.env`                                                                                                                       |
+| secret names are upper-case                                                   | case-insensitive                                    | works: serviceapp's `facturationPassword`                                                                                                                               |
+| public prefixes are `VITE_`, `PUBLIC_`                                        | also `REACT_APP_`, `NEXT_PUBLIC_`                   | works: `REACT_APP_SEGMENT_API_KEY_ADMINS` is reviewed, not blocked                                                                                                      |
+| apps are directories with a `project.json` or a named `package.json`          | the same, from tracked manifests                    | **degrades, silent**: a single-package repository has no app below its root, so rule 3 never fires (0 in 6 of 6)                                                        |
+| rule 8 asks `pnpm exec nx`                                                    | the repository's own nx, only when `nx.json` exists | **degrades, said**: rule 8 skipped with a note (6 of 6)                                                                                                                 |
+| the Node version is in `.node-version`                                        | the same file, not configurable                     | **degrades, said**: a repository with `.nvmrc` only gets the rule 9 note (servicebackoffice)                                                                            |
+| a Dockerfile is any path containing `Dockerfile`                              | read from its name                                  | works: `Dockerfile.prod` is an image                                                                                                                                    |
+| a `COPY` source is a space-separated word                                     | read as Docker reads it                             | **broke, fixed**: servicecontract's quoted `"entrypoint.sh"` was a blocking dead path                                                                                   |
+| local dev-compose Dockerfiles live in `local/`                                | no default, `docker.excludePaths`                   | works                                                                                                                                                                   |
+| the allowlists name monorepo files                                            | empty defaults, `env.config.mjs`                    | works, as a plain object through `npx` and through `defineEnv` from an installed tarball                                                                                |
+
+Two original behaviours stay as they were, because they are judgements, not layout: a final stage
+on an image that is not node (contract-front's `nginx`) is reported as running as root, and a
+variable read by building its name at runtime (serviceapi's `DATABASE_URL_READ2`, found by a
+`process.env` key filter) is reported dead, which `knownExternalPatterns` answers.
+
+`materialize` (seeding test env files from contracts) stays in the monorepo: it writes runtime
+files for one repository's test setup, which is functional, not conformance. Secret scanning by
+VALUE is gitleaks' job and is not part of this role.