docs(protocols): gate credential-leak warnings on project type, not the credential

A session false-alarmed on a leak risk when restoring a credentials doc into a tracked .ai/ file. The reasoning was wrong: a tracked secret is only a public-leak risk where the repo can reach a public remote, which means code projects on public GitHub, the ones that already gitignore .ai/. Personal and documentation projects push to a private single-user repo on cjennings.net, so tracked credentials in their .ai/ files are fine and expected.

I added the rule next to the existing "should .ai/ be committed?" decision in protocols.org, since it's a direct corollary of the same code-vs-personal split. The "is this a leak?" question now resolves on which kind of project and remote it is, not on the mere presence of a credential in a tracked file.

Origin: an elibrary session raised the false alarm and Craig corrected it.

2 files changed, 4 insertions, 0 deletions

diff --git a/.ai/protocols.org b/.ai/protocols.org
index c709010..6e415e3 100644
--- a/.ai/protocols.org
+++ b/.ai/protocols.org
@@ -464,6 +464,8 @@ Claude needs to add information to =.ai/notes.org=. For large amounts of informa
 - Personal/documentation projects usually commit =.ai/= — the project history IS the project
 - =docs/= (when it exists) is typically tracked either way — it's real documentation
 
+**Credential-leak concern: gate it on project type, not on the credential itself.** A tracked secret, token, or credentials doc is only a public-leak risk where the repo can reach a public remote — that is, *code projects pushed to public GitHub*, which is exactly why those gitignore =.ai/= and =.claude/=. For *personal / documentation projects* (the =~/projects/= set: elibrary, home, finances, health, philosophy, etc.), the git remote is a private single-user repo on =cjennings.net=, so tracked credentials inside =.ai/= files are fine — that's the design, the project history IS the project. Do NOT raise a leak warning or suggest gitignoring a secret for these. When the question "is this a leak / should we gitignore this secret?" comes up, decide it on *which kind of project and remote* this is, never on the mere presence of a credential in a tracked file.
+
 **When to break out documents:**
 - If notes.org's Project-Specific Context section gets very large (> 1500 lines) — split into focused reference docs
 - Session records go in =.ai/sessions/= automatically (one file per session via wrap-up workflow) — never mixed into notes.org
diff --git a/claude-templates/.ai/protocols.org b/claude-templates/.ai/protocols.org
index c709010..6e415e3 100644
--- a/claude-templates/.ai/protocols.org
+++ b/claude-templates/.ai/protocols.org
@@ -464,6 +464,8 @@ Claude needs to add information to =.ai/notes.org=. For large amounts of informa
 - Personal/documentation projects usually commit =.ai/= — the project history IS the project
 - =docs/= (when it exists) is typically tracked either way — it's real documentation
 
+**Credential-leak concern: gate it on project type, not on the credential itself.** A tracked secret, token, or credentials doc is only a public-leak risk where the repo can reach a public remote — that is, *code projects pushed to public GitHub*, which is exactly why those gitignore =.ai/= and =.claude/=. For *personal / documentation projects* (the =~/projects/= set: elibrary, home, finances, health, philosophy, etc.), the git remote is a private single-user repo on =cjennings.net=, so tracked credentials inside =.ai/= files are fine — that's the design, the project history IS the project. Do NOT raise a leak warning or suggest gitignoring a secret for these. When the question "is this a leak / should we gitignore this secret?" comes up, decide it on *which kind of project and remote* this is, never on the mere presence of a credential in a tracked file.
+
 **When to break out documents:**
 - If notes.org's Project-Specific Context section gets very large (> 1500 lines) — split into focused reference docs
 - Session records go in =.ai/sessions/= automatically (one file per session via wrap-up workflow) — never mixed into notes.org