envshield 4.2.0__tar.gz → 4.3.0__tar.gz

{envshield-4.2.0 → envshield-4.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: envshield
-Version: 4.2.0
+Version: 4.3.0
 Summary: EnvShield: A CLI for secure local environment management and secret prevention.
 Author-email: Rabbil Yasar Sajal <rabbilyasar@gmail.com>
 License: MIT License
@@ -84,12 +84,14 @@ It works the same way whether you have one repo with one `.env` file, or a monor
 - [Installation](#installation)
 - [Quick start](#quick-start)
   - [A single service](#a-single-service)
-  - [A monorepo with multiple services](#a-monorepo-with-multiple-services)
+  - [A monorepo with multiple services (monorepo)](#a-monorepo-with-multiple-services)
 - [Core concept: the schema is the contract](#core-concept-the-schema-is-the-contract)
   - [Every field a variable can have](#every-field-a-variable-can-have)
   - [Conditional requirements (`requiredIf`)](#conditional-requirements-requiredif)
-  - [Sharing variables across services (`extends`)](#sharing-variables-across-services-extends)
+  - [Sharing variables across services (monorepo, `extends`)](#sharing-variables-across-services-extends)
 - [Command reference](#command-reference)
+  - [Core commands](#core-commands)
+  - [Monorepo: managing multiple services (monorepo)](#monorepo-managing-multiple-services)
 - [Typed config code generation](#typed-config-code-generation)
 - [Validating deployment manifests](#validating-deployment-manifests)
 - [Secret scanning and git hooks](#secret-scanning-and-git-hooks)
@@ -138,22 +140,28 @@ envshield --version
 
 ### A single service
 
-The common case: one repo, one `.env` file.
+The common case: one repo, one `.env` file. This is the whole workflow — nothing else in this README is required to get full value out of EnvShield.
 
 ```bash
 cd my-project
-envshield init                    # Detects your framework, creates env.schema.toml + envshield.yml
-envshield import .env             # Or: seed the schema from an existing .env file
+envshield init                    # Detects your framework and builds env.schema.toml from your real config
 envshield setup                   # Interactive wizard: fills in .env from the schema
 envshield generate --lang python  # Generates a typed config.py (or config.ts for TypeScript)
 ```
 
+`init` looks for a real config source first — an existing `.env`, `.env.example`, or a recognizable Python config module (`config/settings.py` and similar) — and builds the schema from its actual variables, classifying each as secret or not, with a suggested default and, where the value's shape is unambiguous, an inferred type. Only a genuinely fresh project with nothing to read yet falls back to a generic framework template:
+
+```
+Found config/settings.py -- building your schema from its real variables.
+✓ Created/updated schema: env.schema.toml
+```
+
 `init` also offers to install a git pre-commit hook (secret scanning) and a post-merge hook (drift check after every `git pull`) — say yes unless you already have your own hook-management tooling (Husky, `pre-commit`, etc.), in which case EnvShield will detect it and won't clobber it (see [Secret scanning and git hooks](#secret-scanning-and-git-hooks)).
 
-If you already have a real `.env` with real values, `import` is usually the better starting point than `init`'s blank framework defaults — it reads your actual file and classifies each variable (secret or not, with a suggested default and, where the value's shape is unambiguous, a type) in seconds:
+`envshield import <file>` does the same real-variable analysis `init` runs automatically, as its own command — reach for it later, when you want to re-import after adding new variables to your code, point at a file `init` wouldn't have found on its own, or add `--interactive` to confirm each classification by hand instead of accepting the automatic guess:
 
 ```bash
-envshield import .env
+envshield import .env --interactive
 ```
 
 ```
@@ -166,8 +174,14 @@ Analyzing variables...
 - Inferred a type (int/port/bool/url/email) for 3 variable(s).
 ```
 
+---
+
+**Everything above is the complete single-service story.** Everything below this point — multiple services, schema composition, deployment manifests with more than one container — is opt-in, and only relevant once your repo actually has more than one service. Skip straight to [Core concept: the schema is the contract](#core-concept-the-schema-is-the-contract) if that's not you yet.
+
 ### A monorepo with multiple services
 
+*(Optional — skip this if you only have one service.)*
+
 If your repo has more than one service (an API, a web frontend, a worker), run `service discover` at the repo root instead of `init`:
 
 ```bash
@@ -300,6 +314,8 @@ With `FEATURE_X_ENABLED=false`, `FEATURE_X_API_KEY` is optional — `setup` won'
 
 ### Sharing variables across services (`extends`)
 
+*(Monorepo-only — skip this if you have one service.)*
+
 A monorepo with ten services usually has five or six variables every single one of them needs — `LOG_LEVEL`, `SENTRY_DSN`, `DATADOG_API_KEY` — and copy-pasting the same `[LOG_LEVEL]` block into ten schema files is exactly the kind of drift EnvShield exists to prevent.
 
 Factor them into a shared base schema, and have each service extend it:
@@ -336,22 +352,21 @@ Loading `services/api/env.schema.toml` now transparently gives you `LOG_LEVEL`,
 
 ## Command reference
 
-Every command that takes `--service` also works without it: automatically, if there's only one service configured; interactively (or against every service at once, via "All services"), if there's more than one.
+### Core commands
+
+Everything a single-service project ever needs. `--service` shows up on most of these for the multi-service case (see below), but it's entirely optional until you actually have more than one service.
 
 | Command | What it does |
 |---|---|
-| `envshield init [--force/-f]` | Detects your framework, scaffolds `env.schema.toml` + `envshield.yml`, updates `.gitignore`, and offers to install git hooks. Auto-registers a root-level `docker-compose.yml` as the project's deployment manifest if it finds one. `--force` re-runs on a project that already has a config (with a confirmation before overwriting). |
-| `envshield import <file> [--output/-o PATH] [--force/-f] [--interactive] [--service NAME]` | Converts an existing `.env` file or Python config module into `env.schema.toml`, classifying each variable as secret or not, suggesting a default, and inferring a type where the value's shape is unambiguous. `--interactive` confirms each classification with you instead of applying it silently. `--output` changes where the schema is written (defaults to `env.schema.toml`, or the target service's schema path with `--service`). |
+| `envshield init [--force/-f]` | Detects your framework and builds `env.schema.toml` from a real config source if it finds one, otherwise a framework-aware template. Also scaffolds `envshield.yml`, updates `.gitignore`, and offers to install git hooks. Auto-registers a root-level `docker-compose.yml` as the project's deployment manifest if it finds one. `--force` re-runs on a project that already has a config (with a confirmation before overwriting). |
+| `envshield import <file> [--output/-o PATH] [--force/-f] [--interactive] [--service NAME]` | Runs the same real-variable analysis `init` does automatically, as its own command — for re-importing after your code gains new variables, pointing at a file `init` wouldn't have found, or adding `--interactive` to confirm each secret/type classification by hand instead of accepting the automatic guess. `--output` changes where the schema is written (defaults to `env.schema.toml`, or the target service's schema path with `--service`). |
 | `envshield check [file] [--service NAME] [--container NAME]` | Validates a local file (or, if omitted, the project's/service's default local file *and* its registered deployment manifest, if any) against the schema. `file` can be a plain `.env`, a Python config module, a docker-compose file, or a Kubernetes manifest. `--container` picks which service/container to check in a manifest that declares more than one (tried against `--service`'s name automatically first). Exits non-zero on any drift — safe to use as a CI gate. |
 | `envshield doctor [--fix] [--service NAME]` | Runs every health check at once (see below) and reports a summary. `--fix` interactively offers to fix whatever it can — re-running `init`, regenerating the template, installing the git hook, or running `setup` to fill in missing/invalid local values. Exits non-zero if anything's still broken afterward. |
 | `envshield setup [output_file] [--service NAME]` | Interactive onboarding wizard: walks through every variable that's missing, blank, or has an existing value the schema no longer allows, prompting with the variable's description, masking secret input, and offering a picker for `enum` fields. Leaves everything already correct untouched. |
-| `envshield schema sync [--service NAME]` | Regenerates `.env.example` from the schema (a dotenv project), or patches a Python-module local file in place to declare any schema variable it's missing (never rewrites it wholesale — only appends/patches the specific lines it owns). |
+| `envshield schema sync [--service NAME]` | Regenerates `.env.example` from the schema (a dotenv project), or patches a Python-module local file in place to declare any schema variable it's missing (never rewrites it wholesale — only appends/patches the specific lines it owns). `import` already calls this automatically for you when it changes a project's/service's real schema, so you'll rarely need to run it by hand except after a manual schema edit. |
 | `envshield generate [output_file] [--lang/-l python\|typescript] [--force/-f] [--service NAME]` | Compiles the schema into a typed, validated config module. `--lang` is auto-detected from your project (Next.js/Vite/Node.js → TypeScript, everything else → Python) if omitted. Defaults to writing `config.py`/`config.ts`; `--force` overwrites an existing output file. See [Typed config code generation](#typed-config-code-generation). |
 | `envshield scan [paths...] [--staged] [--config/-c PATH] [--exclude/-e PATTERN]` [--service NAME] | Scans code for hardcoded secrets and for env vars used in code (`os.getenv`, `os.environ.get`, `process.env.X`) but never declared in the schema. `--staged` scans only what's staged for the next commit (what the pre-commit hook runs); `--exclude` (repeatable) adds glob patterns to skip, on top of whatever `secret_scanning.exclude_files` is set in `envshield.yml`. See [Secret scanning and git hooks](#secret-scanning-and-git-hooks). |
 | `envshield install-hook` | Installs both git hooks by hand, without going through `init`/`setup`/`service discover`'s interactive prompt. |
-| `envshield service list` | Lists every service currently configured in `envshield.yml`, with its schema and local file paths. |
-| `envshield service add <name> <directory> [--local-file PATH] [--example-file PATH] [--description/-d TEXT] [--schema PATH] [--import FILE] [--deployment-manifest PATH] [--container NAME]` | Registers one service by hand. `--local-file` is required when the service's real config isn't a dotenv file (e.g. a Python module) — see below. `--import` seeds the new service's schema from an existing config file in one step. `--deployment-manifest` is auto-detected (a compose file in the given directory, or the project root) if not given explicitly. |
-| `envshield service discover [root] [--yes/-y]` | Scans for service-like directories not already registered, and offers to add them — see [Quick start](#a-monorepo-with-multiple-services). `--yes` skips the interactive confirmation, for CI/scripting. |
 | `envshield --version` / `-v` | Prints the installed version and exits. |
 
 **Not using a `.env` file at all?** Some projects (a Flask app whose local config is a checked-in Python module, for example) don't use dotenv at all. Point `local_file` at it instead, and EnvShield reads and writes it as source code, not as a dotenv file — appending or patching only the specific assignments it owns, never touching anything else in the file:
@@ -363,6 +378,16 @@ services:
     local_file: athena/config/env_config.local.py
 ```
 
+### Monorepo: managing multiple services
+
+*(Only relevant once your repo has more than one service — see [A monorepo with multiple services](#a-monorepo-with-multiple-services).)* Every core command above already accepts `--service`: automatically, if there's only one service configured; interactively (or against every service at once, via "All services"), if there's more than one.
+
+| Command | What it does |
+|---|---|
+| `envshield service list` | Lists every service currently configured in `envshield.yml`, with its schema and local file paths. |
+| `envshield service add <name> <directory> [--local-file PATH] [--example-file PATH] [--description/-d TEXT] [--schema PATH] [--import FILE] [--deployment-manifest PATH] [--container NAME]` | Registers one service by hand. `--local-file` is required when the service's real config isn't a dotenv file (e.g. a Python module) — see above. `--import` seeds the new service's schema from an existing config file in one step. `--deployment-manifest` is auto-detected (a compose file in the given directory or the project root that actually declares this service) if not given explicitly. |
+| `envshield service discover [root] [--yes/-y]` | Scans for service-like directories not already registered, and offers to add them — see [Quick start](#a-monorepo-with-multiple-services). `--yes` skips the interactive confirmation, for CI/scripting. |
+
 ---
 
 ## Typed config code generation

{envshield-4.2.0 → envshield-4.3.0}/README.md

@@ -29,12 +29,14 @@ It works the same way whether you have one repo with one `.env` file, or a monor
 - [Installation](#installation)
 - [Quick start](#quick-start)
   - [A single service](#a-single-service)
-  - [A monorepo with multiple services](#a-monorepo-with-multiple-services)
+  - [A monorepo with multiple services (monorepo)](#a-monorepo-with-multiple-services)
 - [Core concept: the schema is the contract](#core-concept-the-schema-is-the-contract)
   - [Every field a variable can have](#every-field-a-variable-can-have)
   - [Conditional requirements (`requiredIf`)](#conditional-requirements-requiredif)
-  - [Sharing variables across services (`extends`)](#sharing-variables-across-services-extends)
+  - [Sharing variables across services (monorepo, `extends`)](#sharing-variables-across-services-extends)
 - [Command reference](#command-reference)
+  - [Core commands](#core-commands)
+  - [Monorepo: managing multiple services (monorepo)](#monorepo-managing-multiple-services)
 - [Typed config code generation](#typed-config-code-generation)
 - [Validating deployment manifests](#validating-deployment-manifests)
 - [Secret scanning and git hooks](#secret-scanning-and-git-hooks)
@@ -83,22 +85,28 @@ envshield --version
 
 ### A single service
 
-The common case: one repo, one `.env` file.
+The common case: one repo, one `.env` file. This is the whole workflow — nothing else in this README is required to get full value out of EnvShield.
 
 ```bash
 cd my-project
-envshield init                    # Detects your framework, creates env.schema.toml + envshield.yml
-envshield import .env             # Or: seed the schema from an existing .env file
+envshield init                    # Detects your framework and builds env.schema.toml from your real config
 envshield setup                   # Interactive wizard: fills in .env from the schema
 envshield generate --lang python  # Generates a typed config.py (or config.ts for TypeScript)
 ```
 
+`init` looks for a real config source first — an existing `.env`, `.env.example`, or a recognizable Python config module (`config/settings.py` and similar) — and builds the schema from its actual variables, classifying each as secret or not, with a suggested default and, where the value's shape is unambiguous, an inferred type. Only a genuinely fresh project with nothing to read yet falls back to a generic framework template:
+
+```
+Found config/settings.py -- building your schema from its real variables.
+✓ Created/updated schema: env.schema.toml
+```
+
 `init` also offers to install a git pre-commit hook (secret scanning) and a post-merge hook (drift check after every `git pull`) — say yes unless you already have your own hook-management tooling (Husky, `pre-commit`, etc.), in which case EnvShield will detect it and won't clobber it (see [Secret scanning and git hooks](#secret-scanning-and-git-hooks)).
 
-If you already have a real `.env` with real values, `import` is usually the better starting point than `init`'s blank framework defaults — it reads your actual file and classifies each variable (secret or not, with a suggested default and, where the value's shape is unambiguous, a type) in seconds:
+`envshield import <file>` does the same real-variable analysis `init` runs automatically, as its own command — reach for it later, when you want to re-import after adding new variables to your code, point at a file `init` wouldn't have found on its own, or add `--interactive` to confirm each classification by hand instead of accepting the automatic guess:
 
 ```bash
-envshield import .env
+envshield import .env --interactive
 ```
 
 ```
@@ -111,8 +119,14 @@ Analyzing variables...
 - Inferred a type (int/port/bool/url/email) for 3 variable(s).
 ```
 
+---
+
+**Everything above is the complete single-service story.** Everything below this point — multiple services, schema composition, deployment manifests with more than one container — is opt-in, and only relevant once your repo actually has more than one service. Skip straight to [Core concept: the schema is the contract](#core-concept-the-schema-is-the-contract) if that's not you yet.
+
 ### A monorepo with multiple services
 
+*(Optional — skip this if you only have one service.)*
+
 If your repo has more than one service (an API, a web frontend, a worker), run `service discover` at the repo root instead of `init`:
 
 ```bash
@@ -245,6 +259,8 @@ With `FEATURE_X_ENABLED=false`, `FEATURE_X_API_KEY` is optional — `setup` won'
 
 ### Sharing variables across services (`extends`)
 
+*(Monorepo-only — skip this if you have one service.)*
+
 A monorepo with ten services usually has five or six variables every single one of them needs — `LOG_LEVEL`, `SENTRY_DSN`, `DATADOG_API_KEY` — and copy-pasting the same `[LOG_LEVEL]` block into ten schema files is exactly the kind of drift EnvShield exists to prevent.
 
 Factor them into a shared base schema, and have each service extend it:
@@ -281,22 +297,21 @@ Loading `services/api/env.schema.toml` now transparently gives you `LOG_LEVEL`,
 
 ## Command reference
 
-Every command that takes `--service` also works without it: automatically, if there's only one service configured; interactively (or against every service at once, via "All services"), if there's more than one.
+### Core commands
+
+Everything a single-service project ever needs. `--service` shows up on most of these for the multi-service case (see below), but it's entirely optional until you actually have more than one service.
 
 | Command | What it does |
 |---|---|
-| `envshield init [--force/-f]` | Detects your framework, scaffolds `env.schema.toml` + `envshield.yml`, updates `.gitignore`, and offers to install git hooks. Auto-registers a root-level `docker-compose.yml` as the project's deployment manifest if it finds one. `--force` re-runs on a project that already has a config (with a confirmation before overwriting). |
-| `envshield import <file> [--output/-o PATH] [--force/-f] [--interactive] [--service NAME]` | Converts an existing `.env` file or Python config module into `env.schema.toml`, classifying each variable as secret or not, suggesting a default, and inferring a type where the value's shape is unambiguous. `--interactive` confirms each classification with you instead of applying it silently. `--output` changes where the schema is written (defaults to `env.schema.toml`, or the target service's schema path with `--service`). |
+| `envshield init [--force/-f]` | Detects your framework and builds `env.schema.toml` from a real config source if it finds one, otherwise a framework-aware template. Also scaffolds `envshield.yml`, updates `.gitignore`, and offers to install git hooks. Auto-registers a root-level `docker-compose.yml` as the project's deployment manifest if it finds one. `--force` re-runs on a project that already has a config (with a confirmation before overwriting). |
+| `envshield import <file> [--output/-o PATH] [--force/-f] [--interactive] [--service NAME]` | Runs the same real-variable analysis `init` does automatically, as its own command — for re-importing after your code gains new variables, pointing at a file `init` wouldn't have found, or adding `--interactive` to confirm each secret/type classification by hand instead of accepting the automatic guess. `--output` changes where the schema is written (defaults to `env.schema.toml`, or the target service's schema path with `--service`). |
 | `envshield check [file] [--service NAME] [--container NAME]` | Validates a local file (or, if omitted, the project's/service's default local file *and* its registered deployment manifest, if any) against the schema. `file` can be a plain `.env`, a Python config module, a docker-compose file, or a Kubernetes manifest. `--container` picks which service/container to check in a manifest that declares more than one (tried against `--service`'s name automatically first). Exits non-zero on any drift — safe to use as a CI gate. |
 | `envshield doctor [--fix] [--service NAME]` | Runs every health check at once (see below) and reports a summary. `--fix` interactively offers to fix whatever it can — re-running `init`, regenerating the template, installing the git hook, or running `setup` to fill in missing/invalid local values. Exits non-zero if anything's still broken afterward. |
 | `envshield setup [output_file] [--service NAME]` | Interactive onboarding wizard: walks through every variable that's missing, blank, or has an existing value the schema no longer allows, prompting with the variable's description, masking secret input, and offering a picker for `enum` fields. Leaves everything already correct untouched. |
-| `envshield schema sync [--service NAME]` | Regenerates `.env.example` from the schema (a dotenv project), or patches a Python-module local file in place to declare any schema variable it's missing (never rewrites it wholesale — only appends/patches the specific lines it owns). |
+| `envshield schema sync [--service NAME]` | Regenerates `.env.example` from the schema (a dotenv project), or patches a Python-module local file in place to declare any schema variable it's missing (never rewrites it wholesale — only appends/patches the specific lines it owns). `import` already calls this automatically for you when it changes a project's/service's real schema, so you'll rarely need to run it by hand except after a manual schema edit. |
 | `envshield generate [output_file] [--lang/-l python\|typescript] [--force/-f] [--service NAME]` | Compiles the schema into a typed, validated config module. `--lang` is auto-detected from your project (Next.js/Vite/Node.js → TypeScript, everything else → Python) if omitted. Defaults to writing `config.py`/`config.ts`; `--force` overwrites an existing output file. See [Typed config code generation](#typed-config-code-generation). |
 | `envshield scan [paths...] [--staged] [--config/-c PATH] [--exclude/-e PATTERN]` [--service NAME] | Scans code for hardcoded secrets and for env vars used in code (`os.getenv`, `os.environ.get`, `process.env.X`) but never declared in the schema. `--staged` scans only what's staged for the next commit (what the pre-commit hook runs); `--exclude` (repeatable) adds glob patterns to skip, on top of whatever `secret_scanning.exclude_files` is set in `envshield.yml`. See [Secret scanning and git hooks](#secret-scanning-and-git-hooks). |
 | `envshield install-hook` | Installs both git hooks by hand, without going through `init`/`setup`/`service discover`'s interactive prompt. |
-| `envshield service list` | Lists every service currently configured in `envshield.yml`, with its schema and local file paths. |
-| `envshield service add <name> <directory> [--local-file PATH] [--example-file PATH] [--description/-d TEXT] [--schema PATH] [--import FILE] [--deployment-manifest PATH] [--container NAME]` | Registers one service by hand. `--local-file` is required when the service's real config isn't a dotenv file (e.g. a Python module) — see below. `--import` seeds the new service's schema from an existing config file in one step. `--deployment-manifest` is auto-detected (a compose file in the given directory, or the project root) if not given explicitly. |
-| `envshield service discover [root] [--yes/-y]` | Scans for service-like directories not already registered, and offers to add them — see [Quick start](#a-monorepo-with-multiple-services). `--yes` skips the interactive confirmation, for CI/scripting. |
 | `envshield --version` / `-v` | Prints the installed version and exits. |
 
 **Not using a `.env` file at all?** Some projects (a Flask app whose local config is a checked-in Python module, for example) don't use dotenv at all. Point `local_file` at it instead, and EnvShield reads and writes it as source code, not as a dotenv file — appending or patching only the specific assignments it owns, never touching anything else in the file:
@@ -308,6 +323,16 @@ services:
     local_file: athena/config/env_config.local.py
 ```
 
+### Monorepo: managing multiple services
+
+*(Only relevant once your repo has more than one service — see [A monorepo with multiple services](#a-monorepo-with-multiple-services).)* Every core command above already accepts `--service`: automatically, if there's only one service configured; interactively (or against every service at once, via "All services"), if there's more than one.
+
+| Command | What it does |
+|---|---|
+| `envshield service list` | Lists every service currently configured in `envshield.yml`, with its schema and local file paths. |
+| `envshield service add <name> <directory> [--local-file PATH] [--example-file PATH] [--description/-d TEXT] [--schema PATH] [--import FILE] [--deployment-manifest PATH] [--container NAME]` | Registers one service by hand. `--local-file` is required when the service's real config isn't a dotenv file (e.g. a Python module) — see above. `--import` seeds the new service's schema from an existing config file in one step. `--deployment-manifest` is auto-detected (a compose file in the given directory or the project root that actually declares this service) if not given explicitly. |
+| `envshield service discover [root] [--yes/-y]` | Scans for service-like directories not already registered, and offers to add them — see [Quick start](#a-monorepo-with-multiple-services). `--yes` skips the interactive confirmation, for CI/scripting. |
+
 ---
 
 ## Typed config code generation

envshield-4.3.0/envshield/__init__.py

@@ -0,0 +1 @@
+__version__ = "4.3.0"

{envshield-4.2.0 → envshield-4.3.0}/envshield/cli.py

@@ -1,6 +1,6 @@
 # envshield/cli.py
 import os
-from typing import List, Optional
+from typing import List, Optional, cast
 
 import questionary
 import typer
@@ -92,7 +92,7 @@ def init(
         help="Overwrite existing EnvShield configuration files.",
     ),
 ):
-    """Initializes EnvShield with intelligent, framework-aware defaults."""
+    """Initializes EnvShield -- builds env.schema.toml from your real config if one is found, otherwise a framework-aware template."""
     console.print(
         Panel(
             "[bold cyan]Welcome to EnvShield! Setting up your secure foundation...[/bold cyan]",
@@ -130,7 +130,20 @@ def init(
             )
 
         project_name = os.path.basename(os.getcwd())
-        schema_content = config_manager.generate_default_schema_content(project_type)
+
+        # Prefer building the schema from a real, already-existing config
+        # source over a generic framework template -- a fixed template can
+        # only ever guess at your actual variables.
+        config_source = service_discovery.find_config_source(".")
+        used_real_source = bool(config_source)
+        if config_source:
+            console.print(
+                f"Found [bold yellow]{config_source}[/bold yellow] -- building your schema from its real variables."
+            )
+            schema_content = importer.generate_schema_from_file(config_source, interactive=False)
+        else:
+            schema_content = config_manager.generate_default_schema_content(project_type)
+
         config_manager.write_file(
             config_manager.SCHEMA_FILE_NAME,
             schema_content,
@@ -167,9 +180,15 @@ def init(
         raise typer.Exit()
 
     console.print("\n[bold green]✨ Setup Complete! ✨[/bold green]")
-    console.print(
-        "Your project is now protected. Define your variables in 'env.schema.toml'."
-    )
+    if used_real_source:
+        console.print(
+            "Your project is now protected. Review 'env.schema.toml' -- "
+            "it was built from your real config, but double-check the secret/type guesses."
+        )
+    else:
+        console.print(
+            "Your project is now protected. Define your variables in 'env.schema.toml'."
+        )
     console.print("\n[bold cyan]Next step:[/bold cyan]")
     console.print("  envshield setup    # Configure your local environment")
 
@@ -434,7 +453,8 @@ def generate(
             )
             raise typer.Exit()
 
-        schema = config_manager.load_schema(service_name=service)
+        resolved_service = cast(Optional[str], service_manager.resolve_service(service))
+        schema = config_manager.load_schema(service_name=resolved_service)
         content = generator.generate_config(schema, lang=resolved_lang)
 
         with open(resolved_output, "w") as f:
@@ -481,6 +501,11 @@ def scan(
 ):
     """Scans files for hardcoded secrets and undeclared variables."""
     try:
+        if service:
+            # Validate eagerly for a consistent "Available: ..." error --
+            # run_scan's own service_name=None path means "check every
+            # configured service", so this only fires for an explicit name.
+            service_manager.resolve_service(service)
         scanner.run_scan(
             paths=paths,
             staged_only=staged,
@@ -537,11 +562,8 @@ def import_command(
     try:
         # If service is specified, use that service's schema path
         if service:
-            resolved_output = config_manager.get_service_schema_path(service)
-            if not resolved_output:
-                console.print(f"[bold red]Error:[/bold red] Service '{service}' not found.")
-                raise typer.Exit(code=1)
-            output = resolved_output
+            service_manager.resolve_service(service)
+            output = cast(str, config_manager.get_service_schema_path(service))
 
         if os.path.exists(output) and not force and not interactive:
             console.print(
@@ -565,6 +587,13 @@ def import_command(
         console.print(
             f"\nSuccessfully generated schema at [bold cyan]{output}[/bold cyan]"
         )
+
+        # Keep the tracked template (.env.example) in sync with the schema
+        # we just (re)wrote -- only when `output` is the project's/service's
+        # real configured schema path, not some arbitrary --output destination
+        # there's no template mapping for.
+        if service or output == config_manager.SCHEMA_FILE_NAME:
+            schema_manager.sync_schema(service_name=service)
     except EnvShieldException as e:
         console.print(f"[bold red]Error:[/bold red] {e}")
         raise typer.Exit(code=1)
@@ -643,8 +672,14 @@ def service_add(
     try:
         schema_path = schema or os.path.join(directory, config_manager.SCHEMA_FILE_NAME)
         if not deployment_manifest:
-            deployment_manifest = service_discovery.find_compose_file(directory, ".")
-            if deployment_manifest:
+            found_manifest = service_discovery.find_compose_file(directory, ".")
+            # Auto-discovery only wires it up when the manifest actually
+            # names this service -- an explicit --deployment-manifest below
+            # always overrides this, since that's the user saying so directly.
+            if found_manifest and service_discovery.compose_declares_service(
+                found_manifest, manifest_container or name
+            ):
+                deployment_manifest = found_manifest
                 console.print(
                     f"[dim]Found deployment manifest {deployment_manifest} -- registering it too.[/dim]"
                 )

{envshield-4.2.0 → envshield-4.3.0}/envshield/config/manager.py

@@ -7,6 +7,7 @@ from rich.console import Console
 
 from envshield.core.exceptions import (
     ConfigNotFoundError,
+    ConfigParseError,
     SchemaNotFoundError,
     SchemaParseError,
     UnsafePathError,
@@ -57,9 +58,10 @@ def load_config(path: Optional[str] = None) -> Dict[str, Any]:
         with open(config_path, "r") as f:
             config_data = yaml.safe_load(f)
             return config_data if config_data else {}
-    except (yaml.YAMLError, IOError) as e:
-        console.print(f"[bold red]Error:[/bold red] Failed to parse {config_path}: {e}")
-        raise
+    except yaml.YAMLError as e:
+        raise ConfigParseError(config_path, str(e))
+    except IOError as e:
+        raise ConfigParseError(config_path, str(e))
 
 
 def load_schema(service_name: Optional[str] = None) -> Dict[str, Any]:

{envshield-4.2.0 → envshield-4.3.0}/envshield/core/exceptions.py

@@ -51,6 +51,14 @@ class SchemaParseError(EnvShieldException):
         super().__init__(self.message)
 
 
+class ConfigParseError(EnvShieldException):
+    """Raised when the envshield.yml file cannot be parsed."""
+
+    def __init__(self, config_path: str, details: str):
+        self.message = f"Config parse error in {config_path}: {details}"
+        super().__init__(self.message)
+
+
 class UnsafePathError(EnvShieldException):
     """
     Raised when a path taken from 'envshield.yml' (a service's schema,

{envshield-4.2.0 → envshield-4.3.0}/envshield/core/scanner.py

@@ -444,7 +444,7 @@ def run_scan(
                     skipped_large_files.append(file_path)
                     continue
 
-                # C6: Diff-aware scanning for excluded files
+                # Diff-aware scanning for excluded files
                 new_lines_only = None
                 if file_path in excluded_files:
                     new_lines = _get_diff_lines(file_path)

{envshield-4.2.0 → envshield-4.3.0}/envshield/core/service_discovery.py

@@ -5,6 +5,8 @@
 import os
 from typing import Dict, List, Optional
 
+import yaml
+
 from . import inspector
 from .scanner import DEFAULT_EXCLUDED_DIRS
 from ..parsers.factory import get_parser
@@ -66,6 +68,30 @@ def find_compose_file(service_dir: str, project_root: str = ".") -> Optional[str
     return None
 
 
+def compose_declares_service(compose_path: str, name: str) -> bool:
+    """
+    Whether `name` appears as a top-level service key in the compose file at
+    `compose_path`.
+
+    A shared root compose file is found (by find_compose_file) for every
+    directory being registered, regardless of whether that directory is
+    actually one of its containers. Auto-attaching it unconditionally would
+    silently validate an unrelated service against the wrong container's
+    variables whenever the compose file happens to declare exactly one
+    service -- that single container gets picked with no name check at all
+    (see the parsers' `prefer` logic). Requiring a name match before
+    auto-attaching turns that into "nothing attached, register it by hand
+    with --deployment-manifest" instead of a silent wrong answer.
+    """
+    try:
+        with open(compose_path, "r") as f:
+            doc = yaml.safe_load(f) or {}
+    except (OSError, yaml.YAMLError):
+        return False
+    services = doc.get("services") if isinstance(doc, dict) else None
+    return isinstance(services, dict) and name in services
+
+
 def _looks_like_python_config_module(path: str) -> bool:
     parser = get_parser(path)
     if not parser:
@@ -123,6 +149,34 @@ def _find_dotenv_template(service_dir: str) -> Optional[str]:
     return None
 
 
+def find_config_source(service_dir: str) -> Optional[str]:
+    """
+    Finds the best real config source at `service_dir` to seed a schema
+    from -- a real dotenv file, a checked-in dotenv template, or a
+    recognizable Python config module -- and returns its actual path.
+
+    Unlike detect_env_style, this always returns the real path when one is
+    found, even when it's the conventional '.env'/'.env.example' name --
+    detect_env_style omits that case because its caller only needs to know
+    when a path override is required, while this one is for callers (like
+    'init') that need a real file to read.
+    """
+    real_file = _find_real_dotenv_file(service_dir)
+    if real_file:
+        return real_file
+
+    template_file = _find_dotenv_template(service_dir)
+    if template_file:
+        return template_file
+
+    for rel_path in PYTHON_CONFIG_CANDIDATES:
+        candidate = os.path.join(service_dir, rel_path)
+        if os.path.isfile(candidate) and _looks_like_python_config_module(candidate):
+            return candidate
+
+    return None
+
+
 def detect_env_style(service_dir: str) -> Dict[str, Optional[str]]:
     """
     Looks inside `service_dir` for how it manages environment variables.
@@ -217,11 +271,12 @@ def discover_candidates(
     example_file, deployment_manifest}. `deployment_manifest`, when found,
     is registered automatically -- no '--deployment-manifest' flag needed
     for the common case of a docker-compose file at the project root or
-    inside the service's own directory (see find_compose_file). If its
-    compose file lists more than one service, `check`/`doctor` still work
-    without any extra setup as long as this service's name matches one of
-    the compose service names (see the parsers' `prefer` hint) -- otherwise
-    they'll report exactly which flag/edit resolves the ambiguity.
+    inside the service's own directory (see find_compose_file) that
+    declares a service matching this directory's name (see
+    compose_declares_service). A compose file that doesn't name this
+    service isn't attached at all -- register it by hand with
+    '--deployment-manifest'/'--container' instead of risking a silent
+    validation against the wrong container.
     """
     known_dirs_norm = {os.path.normpath(d) for d in (known_dirs or [])}
     candidates = []
@@ -245,6 +300,10 @@ def discover_candidates(
             name = f"{parent}-{base_name}" if parent else f"{base_name}-{seen_names[base_name]}"
         seen_names[base_name] = seen_names.get(base_name, 0) + 1
 
+        compose_file = find_compose_file(normalized, root)
+        if compose_file and not compose_declares_service(compose_file, base_name):
+            compose_file = None
+
         candidates.append(
             {
                 "name": name,
@@ -253,7 +312,7 @@ def discover_candidates(
                 "format": env_style["format"],
                 "local_file": env_style["local_file"],
                 "example_file": env_style["example_file"],
-                "deployment_manifest": find_compose_file(normalized, root),
+                "deployment_manifest": compose_file,
             }
         )
 

{envshield-4.2.0 → envshield-4.3.0}/envshield/tests/core/test_service_discovery.py

@@ -234,3 +234,55 @@ def test_discover_candidates_includes_deployment_manifest_when_found(tmp_path):
 
     api = next(c for c in candidates if c["name"] == "api")
     assert api["deployment_manifest"] == os.path.normpath(str(tmp_path / "docker-compose.yml"))
+
+
+def test_discover_candidates_does_not_attach_manifest_that_does_not_name_the_service(tmp_path):
+    """
+    Regression: find_compose_file only checks that *a* compose file exists
+    nearby, not that this service is actually declared in it. A shared root
+    compose file with exactly one container would otherwise get silently
+    attached to every unrelated directory discover finds -- and since a
+    single-container compose file is used regardless of --container/prefer,
+    that means validating an unrelated service against the wrong container's
+    variables with no error at all.
+    """
+    (tmp_path / "docs").mkdir()
+    (tmp_path / "docs" / ".env").write_text("KEY=1\n")
+    (tmp_path / "docker-compose.yml").write_text("services:\n  api:\n    image: x\n")
+
+    candidates = service_discovery.discover_candidates(str(tmp_path))
+
+    docs = next(c for c in candidates if c["name"] == "docs")
+    assert docs["deployment_manifest"] is None
+
+
+def test_compose_declares_service(tmp_path):
+    compose = tmp_path / "docker-compose.yml"
+    compose.write_text("services:\n  api:\n    image: x\n  worker:\n    image: y\n")
+
+    assert service_discovery.compose_declares_service(str(compose), "api") is True
+    assert service_discovery.compose_declares_service(str(compose), "docs") is False
+
+
+def test_find_config_source_returns_conventional_dotenv_path(tmp_path):
+    """
+    Unlike detect_env_style (which omits the path for the conventional
+    '.env' name since its caller only needs an override signal),
+    find_config_source always returns the real path -- callers like 'init'
+    need an actual file to read from.
+    """
+    (tmp_path / ".env").write_text("KEY=1\n")
+
+    assert service_discovery.find_config_source(str(tmp_path)) == str(tmp_path / ".env")
+
+
+def test_find_config_source_finds_python_config_module(tmp_path):
+    (tmp_path / "config").mkdir()
+    settings = tmp_path / "config" / "settings.py"
+    settings.write_text("SECRET_KEY = 'x'\nDEBUG = True\nAPI_PORT = 5000\n")
+
+    assert service_discovery.find_config_source(str(tmp_path)) == str(settings)
+
+
+def test_find_config_source_returns_none_when_nothing_found(tmp_path):
+    assert service_discovery.find_config_source(str(tmp_path)) is None

{envshield-4.2.0 → envshield-4.3.0}/envshield/tests/test_cli.py

@@ -362,3 +362,86 @@ def test_check_without_service_runs_for_all_services(mocker, tmp_path):
         assert "── athena ──" in result.stdout
         assert "── hermes ──" in result.stdout
         assert "perfectly in sync" in result.stdout
+
+
+def test_generate_scan_and_import_report_available_services_for_an_unknown_one(tmp_path):
+    """
+    Regression: 'check'/'doctor'/'setup' listed available services on an
+    unknown --service, but 'generate'/'scan'/'import' each had their own
+    inline check with no listing. All should behave the same now.
+    """
+    with runner.isolated_filesystem(temp_dir=tmp_path):
+        _write_two_service_project()
+
+        for args in (
+            ["generate", "--service", "bogus"],
+            ["scan", ".", "--service", "bogus"],
+            ["import", "athena/env.schema.toml", "--service", "bogus"],
+        ):
+            result = runner.invoke(app, args)
+            assert result.exit_code == 1, f"{args}: {result.stdout}"
+            assert "not found" in result.stdout
+            assert "athena, hermes" in result.stdout, f"{args}: {result.stdout}"
+
+
+def test_import_command_syncs_the_env_example_template(tmp_path):
+    """Regression: import used to leave .env.example stale after changing the schema it feeds."""
+    with runner.isolated_filesystem(temp_dir=tmp_path):
+        with open("settings.py", "w") as f:
+            f.write("SECRET_KEY = 'x'\nAPI_PORT = 5000\n")
+
+        result = runner.invoke(app, ["import", "settings.py"])
+
+        assert result.exit_code == 0
+        assert os.path.exists(".env.example")
+        with open(".env.example", "r") as f:
+            content = f.read()
+            assert "SECRET_KEY" in content
+            assert "API_PORT" in content
+
+
+def test_init_builds_schema_from_a_real_config_source_instead_of_the_template(tmp_path, mocker):
+    """
+    Regression: init used to always write the generic framework template even
+    when the project already had real config (e.g. config/settings.py) sitting
+    right there, forcing a separate 'envshield import ... --force' just to get
+    an accurate schema.
+    """
+    with runner.isolated_filesystem(temp_dir=tmp_path):
+        os.system("git init -q")
+        mocker.patch("questionary.confirm").return_value.ask.return_value = False
+        with open("requirements.txt", "w") as f:
+            f.write("Flask\n")
+        os.makedirs("config")
+        with open("config/settings.py", "w") as f:
+            f.write(
+                "SECRET_KEY = 'x'\nDATABASE_URL = 'postgres://x'\n"
+                "DEBUG = True\nAPI_PORT = 5000\nLOG_LEVEL = 'info'\n"
+            )
+
+        result = runner.invoke(app, ["init"])
+
+        assert result.exit_code == 0, result.stdout
+        with open(SCHEMA_FILE_NAME, "r") as f:
+            content = f.read()
+            # The fixed python-flask template only ever has these three --
+            # DEBUG/API_PORT/LOG_LEVEL prove the real file was used instead.
+            assert "DEBUG" in content
+            assert "API_PORT" in content
+            assert "LOG_LEVEL" in content
+
+
+def test_init_falls_back_to_the_framework_template_when_no_real_config_exists(tmp_path, mocker):
+    with runner.isolated_filesystem(temp_dir=tmp_path):
+        os.system("git init -q")
+        mocker.patch("questionary.confirm").return_value.ask.return_value = False
+        with open("requirements.txt", "w") as f:
+            f.write("Flask\n")
+
+        result = runner.invoke(app, ["init"])
+
+        assert result.exit_code == 0, result.stdout
+        with open(SCHEMA_FILE_NAME, "r") as f:
+            content = f.read()
+            assert "SECRET_KEY" in content
+            assert "FLASK_ENV" in content

{envshield-4.2.0 → envshield-4.3.0}/envshield/tests/test_config_manager.py

@@ -4,7 +4,12 @@ import os
 import pytest
 
 from envshield.config import manager as config_manager
-from envshield.core.exceptions import SchemaNotFoundError, SchemaParseError, UnsafePathError
+from envshield.core.exceptions import (
+    ConfigParseError,
+    SchemaNotFoundError,
+    SchemaParseError,
+    UnsafePathError,
+)
 
 
 def test_update_gitignore_creates_file_with_env_pattern(tmp_path, monkeypatch):
@@ -268,6 +273,21 @@ def test_load_schema_supports_multiple_extends_with_later_entries_winning(tmp_pa
     assert schema["SHARED"]["description"] == "from b"
 
 
+def test_load_config_raises_clean_error_on_malformed_yaml(tmp_path, monkeypatch):
+    """
+    Regression: a malformed envshield.yml used to print a message and then
+    re-raise the raw yaml.YAMLError, which no cli.py handler catches (they
+    only catch EnvShieldException) -- producing an unhandled traceback
+    instead of the clean error every other parse failure gets.
+    """
+    monkeypatch.chdir(tmp_path)
+    with open("envshield.yml", "w") as f:
+        f.write("services: [unclosed\n")
+
+    with pytest.raises(ConfigParseError, match="envshield.yml"):
+        config_manager.load_config()
+
+
 def test_load_schema_detects_circular_extends(tmp_path, monkeypatch):
     monkeypatch.chdir(tmp_path)
     with open("a.schema.toml", "w") as f:

envshield-4.2.0/envshield/tests/test_c6_diff_aware_scanning.py → envshield-4.3.0/envshield/tests/test_diff_aware_scanning.py

@@ -1,4 +1,4 @@
-"""Tests for C6: Diff-aware secret scanning in excluded files."""
+"""Tests for diff-aware secret scanning in excluded files."""
 
 from unittest.mock import patch
 

{envshield-4.2.0 → envshield-4.3.0}/envshield/tests/test_service_cli.py

@@ -187,6 +187,25 @@ def test_service_add_auto_detects_compose_file_in_service_directory(tmp_path):
         )
 
 
+def test_service_add_does_not_auto_attach_a_manifest_that_does_not_name_it(tmp_path):
+    """
+    Regression: a shared root compose file used to get auto-attached to
+    any service directory regardless of whether it's actually declared in
+    it -- silently validating against the wrong container. An explicit
+    --deployment-manifest still always works (see the test right below).
+    """
+    with runner.isolated_filesystem(temp_dir=tmp_path):
+        os.makedirs("docs")
+        with open("docker-compose.yml", "w") as f:
+            f.write("services:\n  api:\n    image: x\n")
+
+        result = runner.invoke(app, ["service", "add", "docs", "docs"])
+
+        assert result.exit_code == 0
+        assert config_manager.get_services()["docs"].get("deployment_manifest") is None
+        assert "docker-compose.yml" not in result.stdout
+
+
 def test_service_add_explicit_deployment_manifest_and_container(tmp_path):
     with runner.isolated_filesystem(temp_dir=tmp_path):
         os.makedirs("api")

{envshield-4.2.0 → envshield-4.3.0}/envshield.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: envshield
-Version: 4.2.0
+Version: 4.3.0
 Summary: EnvShield: A CLI for secure local environment management and secret prevention.
 Author-email: Rabbil Yasar Sajal <rabbilyasar@gmail.com>
 License: MIT License
@@ -84,12 +84,14 @@ It works the same way whether you have one repo with one `.env` file, or a monor
 - [Installation](#installation)
 - [Quick start](#quick-start)
   - [A single service](#a-single-service)
-  - [A monorepo with multiple services](#a-monorepo-with-multiple-services)
+  - [A monorepo with multiple services (monorepo)](#a-monorepo-with-multiple-services)
 - [Core concept: the schema is the contract](#core-concept-the-schema-is-the-contract)
   - [Every field a variable can have](#every-field-a-variable-can-have)
   - [Conditional requirements (`requiredIf`)](#conditional-requirements-requiredif)
-  - [Sharing variables across services (`extends`)](#sharing-variables-across-services-extends)
+  - [Sharing variables across services (monorepo, `extends`)](#sharing-variables-across-services-extends)
 - [Command reference](#command-reference)
+  - [Core commands](#core-commands)
+  - [Monorepo: managing multiple services (monorepo)](#monorepo-managing-multiple-services)
 - [Typed config code generation](#typed-config-code-generation)
 - [Validating deployment manifests](#validating-deployment-manifests)
 - [Secret scanning and git hooks](#secret-scanning-and-git-hooks)
@@ -138,22 +140,28 @@ envshield --version
 
 ### A single service
 
-The common case: one repo, one `.env` file.
+The common case: one repo, one `.env` file. This is the whole workflow — nothing else in this README is required to get full value out of EnvShield.
 
 ```bash
 cd my-project
-envshield init                    # Detects your framework, creates env.schema.toml + envshield.yml
-envshield import .env             # Or: seed the schema from an existing .env file
+envshield init                    # Detects your framework and builds env.schema.toml from your real config
 envshield setup                   # Interactive wizard: fills in .env from the schema
 envshield generate --lang python  # Generates a typed config.py (or config.ts for TypeScript)
 ```
 
+`init` looks for a real config source first — an existing `.env`, `.env.example`, or a recognizable Python config module (`config/settings.py` and similar) — and builds the schema from its actual variables, classifying each as secret or not, with a suggested default and, where the value's shape is unambiguous, an inferred type. Only a genuinely fresh project with nothing to read yet falls back to a generic framework template:
+
+```
+Found config/settings.py -- building your schema from its real variables.
+✓ Created/updated schema: env.schema.toml
+```
+
 `init` also offers to install a git pre-commit hook (secret scanning) and a post-merge hook (drift check after every `git pull`) — say yes unless you already have your own hook-management tooling (Husky, `pre-commit`, etc.), in which case EnvShield will detect it and won't clobber it (see [Secret scanning and git hooks](#secret-scanning-and-git-hooks)).
 
-If you already have a real `.env` with real values, `import` is usually the better starting point than `init`'s blank framework defaults — it reads your actual file and classifies each variable (secret or not, with a suggested default and, where the value's shape is unambiguous, a type) in seconds:
+`envshield import <file>` does the same real-variable analysis `init` runs automatically, as its own command — reach for it later, when you want to re-import after adding new variables to your code, point at a file `init` wouldn't have found on its own, or add `--interactive` to confirm each classification by hand instead of accepting the automatic guess:
 
 ```bash
-envshield import .env
+envshield import .env --interactive
 ```
 
 ```
@@ -166,8 +174,14 @@ Analyzing variables...
 - Inferred a type (int/port/bool/url/email) for 3 variable(s).
 ```
 
+---
+
+**Everything above is the complete single-service story.** Everything below this point — multiple services, schema composition, deployment manifests with more than one container — is opt-in, and only relevant once your repo actually has more than one service. Skip straight to [Core concept: the schema is the contract](#core-concept-the-schema-is-the-contract) if that's not you yet.
+
 ### A monorepo with multiple services
 
+*(Optional — skip this if you only have one service.)*
+
 If your repo has more than one service (an API, a web frontend, a worker), run `service discover` at the repo root instead of `init`:
 
 ```bash
@@ -300,6 +314,8 @@ With `FEATURE_X_ENABLED=false`, `FEATURE_X_API_KEY` is optional — `setup` won'
 
 ### Sharing variables across services (`extends`)
 
+*(Monorepo-only — skip this if you have one service.)*
+
 A monorepo with ten services usually has five or six variables every single one of them needs — `LOG_LEVEL`, `SENTRY_DSN`, `DATADOG_API_KEY` — and copy-pasting the same `[LOG_LEVEL]` block into ten schema files is exactly the kind of drift EnvShield exists to prevent.
 
 Factor them into a shared base schema, and have each service extend it:
@@ -336,22 +352,21 @@ Loading `services/api/env.schema.toml` now transparently gives you `LOG_LEVEL`,
 
 ## Command reference
 
-Every command that takes `--service` also works without it: automatically, if there's only one service configured; interactively (or against every service at once, via "All services"), if there's more than one.
+### Core commands
+
+Everything a single-service project ever needs. `--service` shows up on most of these for the multi-service case (see below), but it's entirely optional until you actually have more than one service.
 
 | Command | What it does |
 |---|---|
-| `envshield init [--force/-f]` | Detects your framework, scaffolds `env.schema.toml` + `envshield.yml`, updates `.gitignore`, and offers to install git hooks. Auto-registers a root-level `docker-compose.yml` as the project's deployment manifest if it finds one. `--force` re-runs on a project that already has a config (with a confirmation before overwriting). |
-| `envshield import <file> [--output/-o PATH] [--force/-f] [--interactive] [--service NAME]` | Converts an existing `.env` file or Python config module into `env.schema.toml`, classifying each variable as secret or not, suggesting a default, and inferring a type where the value's shape is unambiguous. `--interactive` confirms each classification with you instead of applying it silently. `--output` changes where the schema is written (defaults to `env.schema.toml`, or the target service's schema path with `--service`). |
+| `envshield init [--force/-f]` | Detects your framework and builds `env.schema.toml` from a real config source if it finds one, otherwise a framework-aware template. Also scaffolds `envshield.yml`, updates `.gitignore`, and offers to install git hooks. Auto-registers a root-level `docker-compose.yml` as the project's deployment manifest if it finds one. `--force` re-runs on a project that already has a config (with a confirmation before overwriting). |
+| `envshield import <file> [--output/-o PATH] [--force/-f] [--interactive] [--service NAME]` | Runs the same real-variable analysis `init` does automatically, as its own command — for re-importing after your code gains new variables, pointing at a file `init` wouldn't have found, or adding `--interactive` to confirm each secret/type classification by hand instead of accepting the automatic guess. `--output` changes where the schema is written (defaults to `env.schema.toml`, or the target service's schema path with `--service`). |
 | `envshield check [file] [--service NAME] [--container NAME]` | Validates a local file (or, if omitted, the project's/service's default local file *and* its registered deployment manifest, if any) against the schema. `file` can be a plain `.env`, a Python config module, a docker-compose file, or a Kubernetes manifest. `--container` picks which service/container to check in a manifest that declares more than one (tried against `--service`'s name automatically first). Exits non-zero on any drift — safe to use as a CI gate. |
 | `envshield doctor [--fix] [--service NAME]` | Runs every health check at once (see below) and reports a summary. `--fix` interactively offers to fix whatever it can — re-running `init`, regenerating the template, installing the git hook, or running `setup` to fill in missing/invalid local values. Exits non-zero if anything's still broken afterward. |
 | `envshield setup [output_file] [--service NAME]` | Interactive onboarding wizard: walks through every variable that's missing, blank, or has an existing value the schema no longer allows, prompting with the variable's description, masking secret input, and offering a picker for `enum` fields. Leaves everything already correct untouched. |
-| `envshield schema sync [--service NAME]` | Regenerates `.env.example` from the schema (a dotenv project), or patches a Python-module local file in place to declare any schema variable it's missing (never rewrites it wholesale — only appends/patches the specific lines it owns). |
+| `envshield schema sync [--service NAME]` | Regenerates `.env.example` from the schema (a dotenv project), or patches a Python-module local file in place to declare any schema variable it's missing (never rewrites it wholesale — only appends/patches the specific lines it owns). `import` already calls this automatically for you when it changes a project's/service's real schema, so you'll rarely need to run it by hand except after a manual schema edit. |
 | `envshield generate [output_file] [--lang/-l python\|typescript] [--force/-f] [--service NAME]` | Compiles the schema into a typed, validated config module. `--lang` is auto-detected from your project (Next.js/Vite/Node.js → TypeScript, everything else → Python) if omitted. Defaults to writing `config.py`/`config.ts`; `--force` overwrites an existing output file. See [Typed config code generation](#typed-config-code-generation). |
 | `envshield scan [paths...] [--staged] [--config/-c PATH] [--exclude/-e PATTERN]` [--service NAME] | Scans code for hardcoded secrets and for env vars used in code (`os.getenv`, `os.environ.get`, `process.env.X`) but never declared in the schema. `--staged` scans only what's staged for the next commit (what the pre-commit hook runs); `--exclude` (repeatable) adds glob patterns to skip, on top of whatever `secret_scanning.exclude_files` is set in `envshield.yml`. See [Secret scanning and git hooks](#secret-scanning-and-git-hooks). |
 | `envshield install-hook` | Installs both git hooks by hand, without going through `init`/`setup`/`service discover`'s interactive prompt. |
-| `envshield service list` | Lists every service currently configured in `envshield.yml`, with its schema and local file paths. |
-| `envshield service add <name> <directory> [--local-file PATH] [--example-file PATH] [--description/-d TEXT] [--schema PATH] [--import FILE] [--deployment-manifest PATH] [--container NAME]` | Registers one service by hand. `--local-file` is required when the service's real config isn't a dotenv file (e.g. a Python module) — see below. `--import` seeds the new service's schema from an existing config file in one step. `--deployment-manifest` is auto-detected (a compose file in the given directory, or the project root) if not given explicitly. |
-| `envshield service discover [root] [--yes/-y]` | Scans for service-like directories not already registered, and offers to add them — see [Quick start](#a-monorepo-with-multiple-services). `--yes` skips the interactive confirmation, for CI/scripting. |
 | `envshield --version` / `-v` | Prints the installed version and exits. |
 
 **Not using a `.env` file at all?** Some projects (a Flask app whose local config is a checked-in Python module, for example) don't use dotenv at all. Point `local_file` at it instead, and EnvShield reads and writes it as source code, not as a dotenv file — appending or patching only the specific assignments it owns, never touching anything else in the file:
@@ -363,6 +378,16 @@ services:
     local_file: athena/config/env_config.local.py
 ```
 
+### Monorepo: managing multiple services
+
+*(Only relevant once your repo has more than one service — see [A monorepo with multiple services](#a-monorepo-with-multiple-services).)* Every core command above already accepts `--service`: automatically, if there's only one service configured; interactively (or against every service at once, via "All services"), if there's more than one.
+
+| Command | What it does |
+|---|---|
+| `envshield service list` | Lists every service currently configured in `envshield.yml`, with its schema and local file paths. |
+| `envshield service add <name> <directory> [--local-file PATH] [--example-file PATH] [--description/-d TEXT] [--schema PATH] [--import FILE] [--deployment-manifest PATH] [--container NAME]` | Registers one service by hand. `--local-file` is required when the service's real config isn't a dotenv file (e.g. a Python module) — see above. `--import` seeds the new service's schema from an existing config file in one step. `--deployment-manifest` is auto-detected (a compose file in the given directory or the project root that actually declares this service) if not given explicitly. |
+| `envshield service discover [root] [--yes/-y]` | Scans for service-like directories not already registered, and offers to add them — see [Quick start](#a-monorepo-with-multiple-services). `--yes` skips the interactive confirmation, for CI/scripting. |
+
 ---
 
 ## Typed config code generation

{envshield-4.2.0 → envshield-4.3.0}/envshield.egg-info/SOURCES.txt

@@ -37,9 +37,9 @@ envshield/parsers/_python.py
 envshield/parsers/factory.py
 envshield/tests/__init__.py
 envshield/tests/conftest.py
-envshield/tests/test_c6_diff_aware_scanning.py
 envshield/tests/test_cli.py
 envshield/tests/test_config_manager.py
+envshield/tests/test_diff_aware_scanning.py
 envshield/tests/test_git_utils.py
 envshield/tests/test_service_cli.py
 envshield/tests/core/__init__.py

{envshield-4.2.0 → envshield-4.3.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "envshield"
-version = "4.2.0"  # must be a string for PEP 621 compliance
+version = "4.3.0"  # must be a string for PEP 621 compliance
 description = "EnvShield: A CLI for secure local environment management and secret prevention."
 readme = "README.md"
 requires-python = ">=3.10"

envshield-4.2.0/envshield/__init__.py

@@ -1 +0,0 @@
-__version__ = "4.2.0"