docs: secrets troubleshooting fixes + framework-version sweep (2.0 → 2.0+) (#190)

* docs(secrets): real diagnostic snippet + rotate-first incident order

- Replace the non-existent dj.config._config_sources line with a working
  snippet that uses find_config_file / find_secrets_dir from
  datajoint.settings to show which paths were resolved.
- Reorder "Accidentally Committed Secrets" so credential rotation is the
  first concrete step — history rewrite is cleanup that doesn't un-leak the
  secret. Add a warning admonition spelling that out, and expand step 1
  with the specific credential classes to rotate (database, object store,
  third-party tokens) and the access-log audit.

* docs: refer to documented framework as DataJoint 2.0+

The docs cover the entire 2.x line, not the 2.0 release specifically.
Switch product-level references from "DataJoint 2.0" to "DataJoint 2.0+"
in README and the how-to / reference / tutorial pages that describe the
framework as it currently exists.

Historical statements ("introduced in 2.0", "What's New in 2.0", paper
citation "DataJoint 2.0: A Computational Substrate...", pre-2.0 vs 2.0
implementation comparisons) intentionally keep their literal version
references.

Author: dimitri-yatsenko

README.md

@@ -1,6 +1,6 @@
 # DataJoint Documentation
 
-Official documentation for [DataJoint](https://github.com/datajoint/datajoint-python) 2.0 — an open-source framework for building scientific data pipelines.
+Official documentation for [DataJoint](https://github.com/datajoint/datajoint-python) 2.0+ — an open-source framework for building scientific data pipelines.
 
 **📖 Live site:** https://docs.datajoint.com
 

src/how-to/deploy-production.md

@@ -12,7 +12,7 @@ Development and production environments have different requirements:
 | Naming | Ad-hoc schema names | Consistent project prefixes |
 | Configuration | Local settings | Environment-based |
 
-DataJoint 2.0 provides settings to enforce production discipline.
+DataJoint 2.0+ provides settings to enforce production discipline.
 
 ## Prevent Automatic Table Creation
 

src/how-to/installation.md

@@ -2,7 +2,7 @@
 
 Install DataJoint Python and set up your environment.
 
-## Install DataJoint 2.0
+## Install DataJoint 2.0+
 
 ```bash
 pip install datajoint

src/how-to/manage-secrets.md

@@ -425,11 +425,21 @@ print(dj.config)
 
 # Check specific setting
 print(dj.config['database.user'])
+```
+
+**Find which files were picked up:**
+
+```python
+from datajoint.settings import find_config_file, find_secrets_dir
 
-# See where value came from
-print(dj.config._config_sources)  # Not a real attribute, just conceptual
+config_path = find_config_file()
+print("config file:", config_path)
+print("secrets dir:", find_secrets_dir(config_path))
 ```
 
+If `find_config_file()` returns `None`, no `datajoint.json` was found via the
+upward search — values come from environment variables and defaults only.
+
 ### Permission Errors
 
 ```bash
@@ -455,10 +465,25 @@ conn = dj.conn(reset=True)
 
 ### Accidentally Committed Secrets
 
-**Immediate actions:**
+!!! warning "Assume the secret is compromised"
+    Once a credential reaches a remote branch, treat it as public. Anyone with
+    repository access — and any service that mirrors or caches commits — may
+    already have it. Rewriting git history does **not** un-leak the secret;
+    rotation does.
+
+**Step 1 — Rotate every exposed credential first.** Do this before touching
+git history; until rotation completes, the leaked secret is still valid.
+
+- Database users (`database.user` / `database.password`): change the password
+  on the server, then update your local `.secrets/datajoint.json`.
+- Object-store credentials (`stores.<name>.access_key` / `secret_key`, or the
+  equivalent in your cloud provider): issue new keys and revoke the old ones.
+- Any third-party tokens that appeared in the same file.
+- Audit recent access logs (DB connection log, S3 access log) for unfamiliar
+  IPs or unexpected activity during the exposure window.
 
-1. **Rotate credentials immediately**
-2. Remove from git history:
+**Step 2 — Remove from git history.** After rotation, scrub the file so old
+clones don't leak it further:
 
 ```bash
 # Remove file from history
@@ -470,7 +495,7 @@ git filter-branch --force --index-filter \
 git push origin --force --all
 ```
 
-3. **Verify removal:**
+**Step 3 — Verify removal:**
 
 ```bash
 git log --all --full-history -- .secrets/datajoint.json

src/how-to/migrate-to-v20.md

@@ -1,6 +1,6 @@
 # Migrate to DataJoint 2.0
 
-Upgrade existing pipelines from legacy DataJoint (pre-2.0) to DataJoint 2.0.
+Upgrade existing pipelines from legacy DataJoint (pre-2.0) to DataJoint 2.0+.
 
 > **This guide is optimized for AI coding assistants.** Point your AI agent at this
 > document and it will execute the migration with your oversight.
@@ -13,14 +13,14 @@ Upgrade existing pipelines from legacy DataJoint (pre-2.0) to DataJoint 2.0.
 
 ### System Requirements
 
-| Component | Legacy (pre-2.0) | DataJoint 2.0 |
+| Component | Legacy (pre-2.0) | DataJoint 2.0+ |
 |-----------|-----------------|---------------|
 | **Python** | 3.8+ | **3.10+** |
 | **MySQL** | 5.7+ | **8.0+** |
 | **Character encoding** | (varies) | **UTF-8 (utf8mb4)** |
 | **Collation** | (varies) | **utf8mb4_bin** |
 
-**Action required:** Upgrade your Python environment and MySQL server before installing DataJoint 2.0.
+**Action required:** Upgrade your Python environment and MySQL server before installing DataJoint 2.0+.
 
 **Character encoding and collation:** DataJoint 2.0 standardizes on UTF-8 encoding with binary collation (case-sensitive comparisons). This is configured **server-wide** and is assumed by DataJoint:
 

src/reference/specs/fetch-api.md

@@ -1,4 +1,4 @@
-# DataJoint 2.0 Fetch API Specification
+# DataJoint 2.0+ Fetch API Specification
 
 ## Overview
 

src/reference/specs/object-store-configuration.md

@@ -8,7 +8,7 @@ DataJoint's Object-Augmented Schema (OAS) integrates relational tables with obje
 
 ### Storage Models
 
-DataJoint 2.0 supports three storage models, all sharing the same store configuration:
+DataJoint 2.0+ supports three storage models, all sharing the same store configuration:
 
 | Model | Data Types | Path Structure | Integration | Use Case |
 |-------|------------|----------------|-------------|----------|

src/tutorials/basics/04-queries.ipynb

@@ -4292,7 +4292,7 @@
    "source": [
     "## Fetching Data\n",
     "\n",
-    "DataJoint 2.0 provides explicit methods for different output formats.\n",
+    "DataJoint 2.0+ provides explicit methods for different output formats.\n",
     "\n",
     "### `to_dicts()` — List of Dictionaries"
    ]