sync: auto-sync from GURU-5070 at 2026-06-12 17:44:04

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-12 17:44:04
This commit is contained in:
2026-06-12 17:44:19 -07:00
parent aebf307a81
commit ac3dbbbec9
2 changed files with 35 additions and 2 deletions

View File

@@ -75,6 +75,7 @@
- [Memory tooling may delete now — additive-only constraint dropped](feedback_memory_sync_destructive_ok.md) — As of 2026-06-02, memory-dream and sync-memory.sh are sanctioned to perform destructive ops (apply proposed merges/dedups, propagate repo deletions back to harness profile stores). Onboarding-phase safety net now fights deliberate consolidation (e.g. 2026-06-01's 39 deletions resurrected on the next sync). Script updates pending. - [Memory tooling may delete now — additive-only constraint dropped](feedback_memory_sync_destructive_ok.md) — As of 2026-06-02, memory-dream and sync-memory.sh are sanctioned to perform destructive ops (apply proposed merges/dedups, propagate repo deletions back to harness profile stores). Onboarding-phase safety net now fights deliberate consolidation (e.g. 2026-06-01's 39 deletions resurrected on the next sync). Script updates pending.
- [Unsaved sessions are recoverable from transcripts](feedback_session_recovery.md) — Crashed/closed-before-save sessions live in `~/.claude/projects/<slug>/*.jsonl`; the detector auto-recovers orphans, `/recover <uuid>` does it manually. Ollama prose + Python verbatim. See `.claude/RECOVERY.md`. - [Unsaved sessions are recoverable from transcripts](feedback_session_recovery.md) — Crashed/closed-before-save sessions live in `~/.claude/projects/<slug>/*.jsonl`; the detector auto-recovers orphans, `/recover <uuid>` does it manually. Ollama prose + Python verbatim. See `.claude/RECOVERY.md`.
- [agy review is not read-only](feedback_agy_review_not_readonly.md) — agy review/review-files CAN write files + run npm despite docs claiming plan-mode; always git diff after and treat Gemini's output as a proposal to validate, not trusted/finished work. - [agy review is not read-only](feedback_agy_review_not_readonly.md) — agy review/review-files CAN write files + run npm despite docs claiming plan-mode; always git diff after and treat Gemini's output as a proposal to validate, not trusted/finished work.
- [Don't present inferred topology as fact](feedback_no_inferred_topology_as_fact.md) — Private-IP overlap (172.16.x on both sides) is NOT proof of a site-to-site link; I fabricated a VWP<->office VPN. State observations vs inferences; a failed reachability test disproves a link, don't explain it away; test "can reach RMM" against the EXTERNAL endpoint, not internal 172.16.3.30.
### Syncro ### Syncro
- [Syncro API plumbing](feedback_syncro_api.md) — Content-Type required on all POST/PUT; NO idempotency anywhere — always GET before retrying; response wrappers (`.ticket.id`, `.comment.id`); add_line_item shape (internal ID, flat response, required fields); HTML uses `<br>` not `<ul>/<li>`; timer_entry response is FLAT but SUPERSEDED (use add_line_item). - [Syncro API plumbing](feedback_syncro_api.md) — Content-Type required on all POST/PUT; NO idempotency anywhere — always GET before retrying; response wrappers (`.ticket.id`, `.comment.id`); add_line_item shape (internal ID, flat response, required fields); HTML uses `<br>` not `<ul>/<li>`; timer_entry response is FLAT but SUPERSEDED (use add_line_item).

View File

@@ -0,0 +1,32 @@
---
name: feedback_no_inferred_topology_as_fact
description: Never present an inferred network link as an observed fact; private-IP overlap is not evidence of a shared fabric, and a failed reachability test disproves a link rather than needing to be explained away.
metadata:
type: feedback
---
On 2026-06-12, investigating VWP-ROSE (Valley Wide Plastering), I concluded Valley
Wide was "Local" to the ACG office via a site-to-site VPN. Mike: there is NO
site-to-site between VWP and the office. I had fabricated the link.
**Why it was wrong:**
- I asserted "VWP-ROSE reached the office RMM server (172.16.3.30) by its real
private IP with no NAT" — I never observed that. Field agents connect to
`rmm-api.azcomputerguru.com` (PUBLIC IP), like ~199/200 of the fleet. `172.16.3.30`
is only *my* office-side base URL; the agent never uses it.
- I read a `172.16.x` overlap (office `172.16.3.x` vs VWP `172.16.9.x`) as a shared
fabric. It is coincidence — `172.16.0.0/12` is RFC1918 space countless unrelated
LANs reuse. Overlapping private ranges prove nothing.
- My own test (force `172.16.3.30` over the corp NIC) FAILED — that disproved the
link. I rationalized it as "asymmetric routing" to preserve my conclusion.
**How to apply:**
- State only what was observed; label inferences as inferences. Never narrate an
unobserved packet/path as if it happened.
- Private-IP overlap is NOT evidence two networks are connected. Require positive
proof (a tunnel config, a successful end-to-end reach with the real source IP).
- When a test contradicts the hypothesis, update the hypothesis — do not invent a
mechanism to dismiss the failure.
- To test "can this adapter reach RMM," use the EXTERNAL endpoint
(`rmm-api.azcomputerguru.com` / its public IP), not the internal `172.16.3.30`.
Nearly every agent is external. See [[reference_gururmm]].