fix(redfix): gitignore config.json (F-redfix-2 remedy) + consume BUILDER-INBOX

Adversary finding F-redfix-2 (non-blocking): config.json sits untracked AND
un-gitignored at both Builder clone roots holding a live-shaped Tinfoil API key
(.provider.tinfoil.options.apiKey) -- one `git add -A` from being pushed to
git.autonomic.zone. Independently re-verified all four claims from my own clone:
untracked, never committed (git log --all -- config.json empty), not ignored,
key live-shaped. Latent risk, NOT an existing leak.

Remedy: add config.json to the "local secrets / env -- never commit" block.
Proved effective by replaying `git add -A` against a scratch GIT_INDEX_FILE:
config.json is no longer staged (only .gitignore, main.go).

Did not delete/move config.json (foreign file, not created by this loop), did
not rotate the key (operator's call -- escalated), did not gitignore main.go
(foreign, but no secret in it), did not reopen redfix or touch REVIEW-redfix.md.
Phase redfix stays DONE; only the Adversary closes F-redfix-2, after re-test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018nVVSxRnj3K5MxGGRJzvTe

machine-docs/BUILDER-INBOX.md

@@ -1,22 +0,0 @@
-# BUILDER-INBOX — from Adversary
-
-**2026-07-08T23:12Z — heads-up, NOT a gate action. Phase `redfix` stays DONE; no VETO.**
-
-I filed **F-redfix-2** (non-blocking) in `machine-docs/BACKLOG-redfix.md`:
-
-`config.json` — at the repo root of BOTH your clones (`/srv/cc-ci/cc-ci`, `/srv/cc-ci-orch/cc-ci`) — holds a
-live-shaped API key at `.provider.tinfoil.options.apiKey`. It is untracked, but **`.gitignore` does not cover
-it**. A single `git add -A` in either clone stages and pushes a live credential to
-`git.autonomic.zone/recipe-maintainers/cc-ci.git`.
-
-I verified it has **never been committed** (`git log --all -S'tk_bhg'` and `git log --all -- config.json` are
-both empty), so this is a latent risk, not an existing leak. Nothing is on fire.
-
-Remedy is yours (repo change; I only file): add `config.json` to the "local secrets / env — never commit"
-block in `.gitignore`. Consider rotating the key if it was ever pasted into a transcript or log. I did not
-touch, move, or delete the file.
-
-Do **not** reopen `redfix` for this — it is outside that phase's Definition of Done. Fold it into whatever
-phase comes next. Only I close F-redfix-2, after re-test.
-
-Consume this file (delete + commit + push) as usual.

machine-docs/JOURNAL-redfix.md

@@ -573,3 +573,40 @@ Node observations (informational — none are phase regressions, none actioned):
   looks like a **live Tinfoil API key**). Deliberately NOT committed — staging `config.json` would
   write a credential into git history — and deliberately NOT deleted, since this loop did not create
   them. Flagged to the operator. Staged nothing via `git add -A` for this reason.
+
+## 2026-07-08T23:08:27Z — consumed BUILDER-INBOX; remediated F-redfix-2 (`config.json` un-gitignored)
+
+Woken by two watchdog pings (a `review(...)` verdict, and BUILDER-INBOX.md appearing). Both pointed at
+the same thing. Phase state re-checked first: `redfix` remains **DONE** — STATUS `## DONE` @2026-06-18T07:09Z,
+M1 PASS @01:18Z, M2 PASS @07:06Z (6/6), **no standing VETO**. No gate action was required of me.
+
+The Adversary's new **F-redfix-2** (BACKLOG-redfix.md, non-blocking) assigned the *remedy* to me while
+reserving closure for itself. I did not take its claims on trust — re-derived each from my own clone:
+
+    git ls-files --error-unmatch config.json  -> error: pathspec ... did not match  (untracked)
+    git log --all --oneline -- config.json    -> (empty)                            (never committed)
+    git check-ignore -v config.json           -> (no match)                         (NOT ignored)
+    .provider.tinfoil.options.apiKey          -> tk_bhg…  len=51                    (live-shaped)
+
+All four confirmed. So: a latent credential-push risk, **not** an existing leak — git history is clean.
+
+**Why `.gitignore` and nothing else.** The exposure is that `git add -A` in either clone stages a live key
+and pushes it to `git.autonomic.zone`. One ignore line removes that path entirely. I proved it rather than
+asserting it — replayed `git add -A` against a throwaway `GIT_INDEX_FILE` seeded from HEAD:
+
+    before: config.json would be staged
+    after : .gitignore, main.go only  — config.json NOT staged
+
+**What I deliberately did NOT do**, and why:
+- **Did not delete/move/rewrite `config.json`.** This loop did not create it (mtime Jun 23, five days
+  after phase DONE) and it is plausibly live operator state. Not mine to destroy.
+- **Did not rotate the key.** Out of my authority and it touches a live external provider. The Adversary
+  is right that rotation is warranted *if* the key was ever pasted into a transcript or log — it appears in
+  at least one journal-adjacent context, so I am escalating rotation to the operator rather than silently
+  deciding it is fine. Flagged, not actioned.
+- **Did not gitignore `main.go`.** Also foreign, but it is a hello-world HTTP server with no secret in it;
+  staging it would be untidy, not dangerous. Ignoring files I did not create is overreach beyond the finding.
+- **Did not reopen `redfix`,** touch REVIEW-redfix.md, or mark F-redfix-2 closed. The Adversary owns closure
+  after re-test; a `.gitignore` line is repo hygiene, not a DoD item, so phase state is unchanged.
+
+`.gitignore` is tracked, so the fix propagates to the sibling clone `/srv/cc-ci/cc-ci` on pull (done below).