Backtalk6858/claude-projects
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update: context.md + playbook — id=51 grill-me complete, session 3/4/5 facts backfilled, N8N API sshTunnel gotcha

Browse Source 
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Backtalk6858
2026-06-21 21:05:37 -05:00
parent 6a90c3bae5
commit 46ff6b247d
2 changed files with 88 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
agent-builder/.claude/context.md
+84 -2
View File
@@ -97,8 +97,8 @@ All 8 prereq checklist items verified live on server-01:
- claude-policy extended: AppRole management + sys/generate-root paths added
### id=57 — REMAINING (next session):
- Sandbox Vaultwarden population — bw CLI approach FAILED (version mismatch); use Vaultwarden REST API directly (id=70 tracks implementation); 53 infra items, dummy values, no production data
- N8N sandbox credentials (-sandbox suffix names)
- Sandbox Vaultwarden bridge fix: 53 ciphers seeded (DB confirmed), but bw CLI WASM crash on list — bridge /items returns 500. Fix: update Vaultwarden image OR rebuild bridge with newer bw CLI OR patch bridge /items to use REST API
- N8N sandbox credentials (-sandbox suffix names) — Bridge API Key already exists; need postgres, Vault, NTFY
- Sudo bridge deploy on server-01 (Phase 2) — then disable NOPASSWD:ALL in /etc/sudoers.d/administrator on server-01
### id=51 — NOT STARTED. Scope locked:
@@ -114,6 +114,88 @@ All 8 prereq checklist items verified live on server-01:
- ids added: 69 (Vaultwarden Version Monitor, p16), 70 (Sandbox Vaultwarden Seeder, p17)
- feedback_bw_cli_vaultwarden_create.md added to docker MEMORY.md
## June 20 Session 3 (continuation)
### Sandbox Vaultwarden — 53/53 dummy ciphers seeded (DB confirmed)
- Root cause of login failure: Bitwarden-Client-Version header required by Vaultwarden 1.36.0
- Original akey was encrypted with unknown master key (registration vs unlock password mismatch)
- Fix: reset sandbox@test.local password_hash + akey in postgres-sandbox via /tmp/vw_reset_and_seed.py
- Script: derives keys from u8X_P_zlGBypRUXYq5iGIg + PBKDF2/HKDF, generates fresh user_sym_key,
updates DB directly, logs in via REST API, POSTs 53 AES-256-CBC encrypted ciphers
- Runs via: `docker run --rm --network n8n-sandbox_default -v /tmp/vw_reset_and_seed.py:/tmp/script.py bitwarden-bridge:sandbox sh -c 'pip install cryptography psycopg2-binary --quiet && python3 /tmp/script.py'`
- Script at /tmp/vw_reset_and_seed.py on server-01 (also /tmp/vw_reset_and_seed.py locally)
- 53 ciphers confirmed: `SELECT COUNT(*) FROM ciphers WHERE user_uuid='896b5bbb-...'` → 53
- Bridge unlocks successfully with new password on every restart
### BLOCKER: bw list items WASM crash (same as bw create)
- Error: "Invalid key, throwing away stored keys" × 2, then "invalid type: unit value, expected a valid string"
- Empty vault worked; non-empty vault fails — bw CLI 2026.5.0 can't decrypt Vaultwarden 1.36.0 ciphers
- Bridge /items returns 500 error; ciphers ARE in DB but not serveable via bridge
- Fix options (next session, pick one):
1. Pull updated vaultwarden/server:latest (Docker pull currently broken due to daemon instability on server-01 — containerd-based Docker 29.x; images intact at /var/lib/containerd 26G)
2. Rebuild bitwarden-bridge:sandbox with newer bw CLI version
3. Patch bridge /items endpoint to use Vaultwarden REST API instead of bw CLI
- /tmp/vw_reset_and_seed.py script is reusable — if Vaultwarden is updated, just re-run to re-seed after container recreate
### Docker daemon incident (unrelated to our work)
- All containers exited during session — Docker 29.x daemon crash (not caused by our actions)
- Images are in /var/lib/containerd (26G), not /var/lib/docker/overlay2 (new storage model)
- Stack brought back up via: `cd /opt/appdata/docker/docker-compose/server-01 && docker compose up -d`
- Compose file location confirmed: /opt/appdata/docker/docker-compose/server-01/docker-compose.yml
### id=57 — COMPLETE ✅ (June 20 Session 5)
All sandbox prereqs done. Sandbox mirrors production.
**Completed in Session 5:**
- Bridge switched to Bitwarden cloud (megafreeman12@proton.me) — unlocks cleanly, /items returns 53
- Compose updated: BW_SERVER and NODE_TLS_REJECT_UNAUTHORIZED removed; vaultwarden-sandbox depends_on removed
- 53 dummy items seeded (dummy-infra-01 through dummy-infra-53)
- sandbox Vault secret/bitwarden updated with new master_password
- N8N sandbox credentials created: postgres-sandbox, vault-sandbox, n8n-internal-sandbox, Bridge API Key (Sandbox)
- n8n_agent_worker postgres role — api_business DB, scoped to automation_ideas + agent_test_results
- Credential in production Vault: secret/postgres/n8n-agent-worker
### REMAINING BEFORE BUILDER AGENTS:
- id=51 Secrets Execution Proxy — grill-me COMPLETE (June 21 session 4), build next session
- HTTP + shell commands; vault:// + bitwarden:// backends; per-caller auth keys in Vault
- Shell: sandbox-first always; tiered gate (read=auto, write=notify-after, destructive=blocking NTFY)
- Result redaction: literal secret replacement + pattern scan second pass
- Training: every execution logged (caller, command, sandbox result, real result, approval, redaction events)
- Deploy: server-01, Docker, Traefik + Cloudflare
### June 21 session 2 facts for next session:
- server-01 Coolify UUID: hvzbj1gkqb5696s7cc9lcf8y
- Sandbox stack Coolify service UUID: d2celewbvh7e4fer77fcp9b5
- n8n-prod Coolify service UUID: h10eww4au274owpxozgizysh
- Traefik on primary binds to 127.0.0.1:80 only (LAN push workaround: docker save | ssh | docker load on primary then push)
- sudo_bridge DB: server_id column added to executions + allowlist_changes, default='primary'
- app.py needs: server_id='server-01' + [server-01] NTFY prefix variant for server-01 deployment
- sudo-bridge image: gitea.local/backtalk6858/sudo-bridge:latest (same image, different env vars)
- sudo-bridge-server01 Coolify UUID: o2kz1puml1mmneyiqd96mouj (port 8082, pull_policy:never)
- Vault secret created: secret/data/sudo-bridge-server01 (api_key: 443ea35b43c3e640aac3c57ed3aae06b8822ab6f)
- Host daemon running: /opt/appdata/docker/sudo-bridge/sudo_bridge_daemon.py (systemd, enabled)
- vaultwarden-sandbox REMOVED from sandbox stack (no longer needed — Bitwarden cloud dummy account used)
- app.py updated: SERVER_ID, _server_prefix(), server_id audit writes, User-Agent for Cloudflare
- NTFY approval action buttons use BRIDGE_EXTERNAL_URL=http://192.168.1.90:8082 (LAN only until Tailscale)
- NOPASSWD:ALL disabled on server-01 ✅ (June 21 session 3)
- Both bridges now on public URLs via Traefik + Cloudflare: sudo-bridge.reverseproxyserver.net + sudo-bridge-server01.reverseproxyserver.net
- Danger veto in daemon blocks rm /etc/* regardless of allowlist — /etc sudoers removal done manually
- NEXT: id=51 Secrets Execution Proxy (grill-me DONE June 21 session 4 — build next session)
## June 20 Session 4 (continuation)
### Docker 29.6.0 crash — diagnosed and fixed
- Root cause: nala upgrade swept in Docker 29.6.0 which has SIGSEGV null pointer dereference bug in HTTP transport during docker pull
- Fix: downgraded to 29.5.3, pinned with `apt-mark hold docker-ce docker-ce-cli docker-ce-rootless-extras`
- Rule: never run nala/apt upgrade without holding docker-ce first
### bw CLI + Vaultwarden — permanently abandoned
- bw CLI 2026.4.1 AND 2026.5.0 both crash against Vaultwarden 1.36.0 with `orgKeys null` TypeError
- Root cause: Vaultwarden returns null for orgKeys in sync response for personal vaults; bw CLI expects {}
- Decision: drop Vaultwarden sandbox, use Bitwarden cloud dummy account (same as production)
- Dummy account created: megafreeman12@proton.me, master_password=Infra6746Dummy$
- All credentials stored at secret/sandbox/bitwarden in production Vault (4 fields: email, master_password, client_id, client_secret)
- Sandbox bridge Dockerfile.sandbox moved to /opt/appdata/docker/docker-compose/server-01/bitwarden-bridge/ (pinned bw CLI 2026.4.1 — moot now but kept for reference)
- bridge:sandbox image rebuilt and pushed to gitea.reverseproxyserver.net (still has bw CLI 2026.4.1)
## June 22 (Monday) — Builder Agents (extended session)
Build, test, and push both builder agents to production. Work as long as it takes.
- id=24 Agent Builder Agent (claude_agent + script types)
agent-builder/.claude/playbook_n8n_builder_agent.md
+4
View File
@@ -207,3 +207,7 @@ Sandbox credentials must be named with a `-sandbox` suffix to distinguish from p
- `n8n-internal-sandbox` (not `n8n-internal`)
This prevents the N8N Builder Agent from accidentally referencing production credentials when building sandbox workflows.
## N8N API gotchas
When creating postgres credentials via the N8N REST API, always include `"sshTunnel": false` in the data object — the schema requires this field even when SSH tunneling is not used. Omitting it returns HTTP 400 with a long allOf schema error.