
  Usage: gina secrets:<action> [options]

  Introspect the ${secret:KEY} placeholders your bundle configs require.
  Read-only: these commands never resolve a secret, never read a value,
  and never write anything.

  Actions:

    scan                         Report required secrets for every bundle in
                                 every registered project.
    scan @<project>              Report required secrets for every bundle in
                                 <project>, aggregated as KEY <- config file(s).
    scan <bundle> @<project>     Scope the report to one bundle.
    scan @<project> --format=json
                                 Machine-readable JSON output (CI / tooling).

    check                        For every required key, report SET / UNSET
                                 against the current environment. Exits
                                 non-zero if any required key is unset.
    check @<project>             Check every bundle in <project>.
    check <bundle> @<project>    Check one bundle.
    check @<project> --format=json
                                 Machine-readable JSON output. The exit code
                                 still reflects unset keys.

    help                         Show this help.

  Options:

    --format=<text|json>         Output format. Default `text`.
    --scope=<scope>              Overlay the sibling `config_<scope>/` dirs over
                                 the base config (read-only deep-merge, scope
                                 wins) so the report shows the EFFECTIVE keys
                                 that scope's deploy requires. Scope must be
                                 registered (see `gina scope:list`).
    --env-file=<path>            (check) Validate against a `.env`-style file's
                                 vars instead of the live process.env — e.g. a
                                 decrypted SOPS export or a CI-exported env.

  Examples:

    $ gina secrets:scan @myproject
    $ gina secrets:scan demo @myproject --format=json
    $ gina secrets:check @myproject
    $ export DB_PASSWORD=... API_KEY=... && gina secrets:check @myproject
    $ gina secrets:scan @myproject --scope=production
    $ gina secrets:check @myproject --scope=production --env-file=/run/secrets.env

  Config sources scanned (matching the runtime config loader):
    <bundleSrc>/config/*.json   per bundle (`bundleSrc` from manifest `src`)
    shared/config/*.json        project-level; merged into every bundle
    with --scope=<s>            the sibling `config_<s>/` dirs are read-only
                                overlaid on top (deep-merge, scope wins) — the
                                same per-scope config a deploy applies; the
                                runtime config loader itself stays scope-agnostic.

  Notes:
    - `scan` reads the placeholders authored on disk, not the merged
      runtime config. Mixed-content strings such as
      `https://${secret:HOST}/path` are NOT reported — only a bare
      `${secret:KEY}` value is a placeholder (mirrors how the resolver
      substitutes).
    - `check` validates the environment of THIS CLI process, not a
      detached bundle's runtime/container environment. Use it in CI after
      exporting the secrets, or in a shell that sourced the same env file —
      it cannot introspect an already-running bundle.
    - A key counts as SET only when it is a non-empty string, the same
      condition under which the bundle would start without a secret error.

  Reference: https://gina.io/docs/guides/secrets
