docs: the .env change was a fix, and two lists had gone stale (#21)

**The changelog entry moves from Changed to Fixed.** The larger half of it
was a defect: `--env-file` has said "instead of looking for one" in its own
help since the day it was added, and read the named file after everything the
search found. A flag meant to make one client entry self-contained isolated
nothing, because a setting the named file omitted was still answered by
whatever was on the machine. The entry now says that, and separates it from
the half that is a decision - the search taking the highest file rather than
layering them, so both configuration files follow one rule.

SPECS 6 gains the same split, since the reasoning is what that section is for.

**SPECS 14.1 still said questions 2 and 3 need write calls against a test
account.** Both were answered on 2026-08-20 and 21 and are struck through in
section 16, which states two paragraphs later that nothing is left a test
account could answer. The sentence now describes how the questions were
actually closed.

**The layout in these guidelines had lost two modules**: `articles` among the
tool groups and `stamp` in the interface. Both are named in SPECS 4, so the
two documents disagreed about what the tree contains.

Checked and unchanged: twenty-five tools, a tool list of 52,221 characters,
the longest description at 674, coverage 95.63% against a badge that says 96,
every section reference resolving, and the README tables against the registry.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: BeneODev

CHANGELOG.md

@@ -13,16 +13,23 @@ housekeeping are out of scope here — design decisions live in
 
 ## [Unreleased]
 
-### Changed
+### Fixed
+
+- **`--env-file` now reads that file and no other.** Its help has always said
+  "instead of looking for one", and it did not: the named file was read
+  *after* every file the search found, so a setting missing from it was still
+  supplied by whatever else happened to be on the machine. Pointing at a file
+  is now what it appears to be.
+
+  The search behind it follows the same rule: the highest-precedence `.env`
+  that exists is the file, and the ones below it are not read. That half was
+  deliberate before and is a decision rather than a defect - one rule for both
+  configuration files, since `--tools-file` and the policy search never
+  combined anything either.
 
-- **One `.env` applies now, never several.** The settings files used to be
-  merged key by key, so a value could arrive from a file you had not named and
-  had no reason to look at. The highest-precedence file that exists is the
-  file, and the ones below it are not read. `--env-file` names it and skips
-  the search entirely, which is what `--tools-file` has always done for the
-  policy file. A real environment variable still beats whatever the file says,
-  so a container can pass its transport settings while the key lives in the
-  mounted file.
+  A real environment variable still beats whatever the file says, so a
+  container can pass its transport settings while the key lives in the mounted
+  file.
 
   **This can change what your server reads.** If a setting of yours lives in a
   lower-precedence file - a per-user `.env` under a checkout that has its own,

CLAUDE.md

@@ -79,12 +79,12 @@ src/benethos_lexware_office_mcp/
   transport.py    # HTTP: the bearer guard, the host allowlist, the settings watch
   envfile.py      # reading and writing a .env, comments left alone
   configui/       # the local configuration interface, `setup` serves it
-                  # render, state, cost, probe, profiles, transfer,
-                  # pages, app - never part of the MCP server process
+                  # render, state, cost, probe, stamp, profiles,
+                  # transfer, pages, app - never part of the server process
   tools/
     _base.py      # registration helper, tidies the docstring first
     <group>.py    # one module per resource group, thin tool definitions
-                  # built: diagnostics, contacts, vouchers,
+                  # built: diagnostics, contacts, vouchers, articles,
                   #        sales_documents, files, master_data
 tests/            # offline, httpx MockTransport
   smoke.py        # read-only live check, run by hand, never collected

SPECS.md

@@ -690,14 +690,23 @@ still meets it.
 - **One `.env` applies, and the environment beats it.** A setting resolves as
   that one file, then the real environment, which has the last word - the
   order Docker and uvicorn use, and what lets a client override one value
-  without rewriting a file. **The files themselves do not combine**, changed
-  on 2026-08-23: they used to merge key by key, so a value could arrive from a
+  without rewriting a file. **The files themselves do not combine**, since
+  2026-08-23: they used to merge key by key, so a value could arrive from a
   file nobody had named and no page could sensibly report where it came from.
-  Naming one with `--env-file` now replaces the search, exactly as
-  `--tools-file` always did, and the search itself takes the highest candidate
-  that exists rather than layering them. The environment stays a separate
-  layer because the container depends on it: the transport settings arrive as
-  real variables while the key lives in the mounted file.
+
+  **Half of that was a defect rather than a decision.** `--env-file` was
+  documented as naming the file "instead of looking for one" from the day it
+  was added, in its own help text, in the epilog and in the table below, and
+  the code read it *after* every file the search found. So a flag whose whole
+  purpose was to make one client entry self-contained did not isolate
+  anything: a setting the named file omitted was still answered by the
+  machine. It now replaces the search, exactly as `--tools-file` always did.
+
+  The other half is a decision: the search takes the highest candidate that
+  exists rather than layering them, so both configuration files follow one
+  rule and "which file is this value from" has one answer. The environment
+  stays a separate layer because the container depends on it: the transport
+  settings arrive as real variables while the key lives in the mounted file.
   `--log-level` and `--tools-file` are the two flags that outrank the
   environment, because each is a decision about this one run. `--tools` and
   `--version` are actions rather than settings and have no equivalent at all.
@@ -1825,9 +1834,11 @@ The consequences are the point of writing this down.
   shapes. Only a live run catches that, and only someone holding an account
   can perform one. This is why statements about the API in this document carry
   **(to verify)** until a live call has confirmed them.
-- **The open questions below cannot be closed by CI.** Questions 2 and 3 need
-  write calls against a disposable test account, see section 11.1. That is a
-  deliberate act by the account owner, not something automation initiates.
+- **The open questions below could not be closed by CI**, and none of them was.
+  Each was answered by a live call, or in one case by a decision not to make
+  one: a question about write behaviour needs write calls against a disposable
+  test account, see section 11.1, which is a deliberate act by the account
+  owner rather than something automation initiates.
 
 ## 15. Conventions