sync: auto-sync from GURU-KALI at 2026-05-27 06:00:19

Author: Mike Swanson
Machine: GURU-KALI
Timestamp: 2026-05-27 06:00:19
This commit is contained in:
2026-05-27 06:00:20 -07:00
parent 2678d382a7
commit f361b328fe

View File

@@ -0,0 +1,71 @@
# Session Log — identity.json Phase-2 migration + attribution follow-ups
Continuation of 2026-05-26 GURU-KALI work (see `2026-05-26-guru-kali-attribution-hardening.md` for the attribution hardening, memory sweep, and Ollama/Pluto rounds that precede this).
## User
- **User:** Mike Swanson (mike)
- **Machine:** GURU-KALI
- **Role:** admin
- **Session span:** 2026-05-26 ~20:05 MST through 2026-05-27 ~06:00 MST
## Session Summary
Picked up a coord message from the Mac directing Phase 2 of identity.json centralization: pull the new `migrate-identity.sh`, run it, review, reply. Before running a script that rewrites the identity.json edited earlier this session, read both the script and the `proposal_identity_centralization.md` rationale. Confirmed the migration is additive/non-destructive, then ran it — it added `python`, `ollama` (endpoint/fallback/prose_model), `platform`, `architecture`, `last_updated`.
The migration's `ollama` object overlapped with the interim `ollama_fallback` field added earlier the same day. Converged on the Mac's canonical `ollama.*` schema: removed the redundant `ollama_fallback`, and realigned the three docs touched earlier (OLLAMA.md, CLAUDE.md, feedback_ollama_tier0_routing.md) to read `.ollama.endpoint` via `jq` instead of the old field. Replied to the Mac flagging that those three docs were already aligned, so its Phase-2 step 4 only needed sync.sh + syncro.md. The Mac then landed exactly that (`2c12bd2`), plus a Windows-bug fix to migrate-identity.sh (`251bb35`) and CLAUDE.md cleanup (`0e2629a`). All concurrent edits to shared files (sync.sh three times, the Ollama docs) merged without conflict; verified each merge preserved the attribution guards and produced single, non-duplicated resolvers.
Resolved the outstanding hooks question: the Mac replied that `install-hooks.sh` has NOT been run on Mikes-MacBook-Air (submodule initialized, only `.sample` hooks present), so `project_mac_gururmm_setup_pending.md` stays. Updated its caveat from "verify/maybe-delete" to `[CONFIRMED PENDING 2026-05-27]`. At Mike's direction, filed the action as a coord to-do scoped to the Mac so that machine owns its own task.
Also evaluated the Pluto/Neptune SSH key-rotation question via the GuruRMM API (read-only dispatch): Pluto's old `guru@DESKTOP-0O8A1RL` key is already rotated out (current keys are the build server's); Neptune has no SSH authorized_keys at all. Updated reference_pluto_build_server.md to the verified state.
## Key Decisions
- Read `migrate-identity.sh` + the proposal before running — it rewrites the same identity.json edited earlier; confirmed additive (only adds keys, preserves existing) before executing.
- Adopted the Mac's `ollama.{endpoint,fallback,prose_model}` schema as canonical and removed my interim top-level `ollama_fallback` to avoid two competing Ollama configs. The richer schema is what the rollout wires scripts to.
- Realigned the three Ollama docs to `.ollama.endpoint` immediately (convergent with the Mac's direction, not conflicting) rather than leaving them pointing at a removed field.
- Filed the Mac hooks action as a coord to-do (not just a memory note) per Mike; scoped `assigned_to_machine` to `Mikes-MacBook-Air.local` (the Mac's actual `hostname`, which its sync.sh passes as `for_machine`) so it actually surfaces there — verified by querying.
- Evaluated keys via RMM read-only dispatch; did NOT add/rotate any key (Mike said evaluate). Surfaced the GURU-5070-key-not-on-Pluto finding as a decision, not an action.
## Problems Encountered
- Concurrent overlapping edits with the Mac session on shared files (sync.sh, Ollama docs) three times — each rebase merged cleanly, but verified post-merge that the attribution guards (reconcile_git_identity, unknown-sentinel guard, stale-hostname warning) and the single `.ollama.endpoint` resolver survived intact. Flagged to Mike that both sessions are working unlocked (coord lock protocol available if a tangle arises).
- zsh `status` is a read-only variable — the RMM dispatcher script aborted under the Bash tool's zsh. Re-ran the dispatcher under `bash` and renamed the local to `st`; also moved the PowerShell payload to a file to avoid nested-heredoc quoting.
- Coord to-do `.local` targeting: the Mac's identity is `Mikes-MacBook-Air` but its `hostname` (and thus sync.sh `for_machine`) is `Mikes-MacBook-Air.local`. Assigned the to-do to the `.local` form and verified it surfaces on the Mac's query and not on GURU-KALI's.
## Configuration Changes
- `.claude/identity.json` (gitignored, per-machine) — migrate-identity.sh added `python`, `ollama`, `platform`, `architecture`, `last_updated`; then removed the interim `ollama_fallback`.
- `.claude/memory/feedback_ollama_tier0_routing.md` — resolver now `jq -r '.ollama.endpoint // .ollama.fallback'`; "superseded ollama_fallback" breadcrumb.
- `.claude/OLLAMA.md`, `.claude/CLAUDE.md` — Ollama resolver/table realigned to `.ollama.endpoint` (then further cleaned by the Mac's `0e2629a`/`2c12bd2`).
- `.claude/memory/reference_pluto_build_server.md` — authorized-key line replaced with RMM-verified current keys.
- `.claude/memory/project_mac_gururmm_setup_pending.md` — caveat updated to `[CONFIRMED PENDING 2026-05-27]`.
## Credentials & Secrets
None created or discovered. RMM API auth used existing SOPS creds at `infrastructure/gururmm-server.sops.yaml` (claude-api@azcomputerguru.com). No secret values exposed.
## Infrastructure & Servers
- GuruRMM API `http://172.16.3.30:3001` — reachable from GURU-KALI; 60 agents enrolled. PLUTO `5316f56f-a1b3-4ac5-97ac-71ddf6a74d2e` (172.16.3.36), NEPTUNE `7d4f823c-f23d-40b8-ae72-b83cd2ccb09d`.
- Pluto authorized keys (verified 2026-05-26): `gururmm-build@gururmm-server`, `guru@gururmm-build`; old `guru@DESKTOP-0O8A1RL` gone. Neptune: no SSH authorized_keys.
- GURU-KALI identity.json `ollama`: endpoint+fallback `http://100.101.122.4:11434` (Beast), prose_model qwen3:14b; python.command python3; platform linux; arch amd64.
## Commands & Outputs
- `bash .claude/scripts/migrate-identity.sh` → added python/ollama/platform/arch (detected python3/linux/amd64/Beast/qwen3:14b).
- Resolver verified: `jq -r '.ollama.endpoint // .ollama.fallback // "http://localhost:11434"' .claude/identity.json``http://100.101.122.4:11434`. jq 1.8.1 present.
- Coord to-do created: `c28d1baa-202a-4718-aa03-488288c80f9a` (assigned Mikes-MacBook-Air.local, user mike, project gururmm). Verified it surfaces on `GET /api/coord/todos?for_user=mike&for_machine=Mikes-MacBook-Air.local&status_filter=pending` and not on GURU-KALI's query.
- Coord replies sent: identity migration confirm `810196fc`; (earlier) hooks question `625d80a7`. Mac hooks reply received `read_at 2026-05-27T02:53`.
## Pending / Incomplete Tasks
Per Mike (2026-05-27), none of the following belong to this instance anymore — recorded for continuity only:
- Mac `install-hooks.sh` — now owned by the Mac via coord to-do `c28d1baa`.
- Ollama config rollout to other machines — driven by the Mac's Phase-2 rollout.
- Add GURU-5070's pubkey to Pluto (so the documented workstation-SSH workflow works) — not this instance's task.
## Reference Information
- Commits this session: `262fd8d` (Ollama reconciliation), `2678d38` (mac-pending caveat). Pulled: Mac `2c12bd2`/`251bb35`/`0e2629a` (Phase-2 step 4 + fixes), Howard GuruScan module refactor.
- Coord to-do: `c28d1baa-202a-4718-aa03-488288c80f9a`.
- Migration script: `.claude/scripts/migrate-identity.sh`; proposal: `.claude/memory/proposal_identity_centralization.md`.