azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from GURU-5070 at 2026-06-08 06:50:14

Browse Source 
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-08 06:50:14
This commit is contained in:
Mike Swanson
2026-06-08 06:50:18 -07:00
parent 14362628a2
commit 41450301dc
4 changed files with 188 additions and 428 deletions
Download Patch File Download Diff File Expand all files Collapse all files

484
.claude/commands/feature-request.md
View File

@@ -1,473 +1,101 @@
GuruRMM Feature Request — Comprehensive Analysis & Specification
# GuruRMM Feature Request -> RMM Thoughts
When Howard (or Mike) submits a feature request, conduct full research and produce a detailed specification with implementation recommendations.
When Howard (or Mike) submits a GuruRMM feature request, **capture it as a raw entry in
the RMM Thoughts backlog** — do NOT jump straight to a full spec or the roadmap. Those
are downstream, decision-gated stages.
Pipeline (see `.claude/memory/feedback_rmm_thoughts_backlog.md`):
**THOUGHT (this command, Status: Raw) -> DISCUSS -> SPEC (`/shape-spec` -> `specs/<slug>/`)
-> ROADMAP (`docs/FEATURE_ROADMAP.md`) -> BUILD.**
Backlog doc: `projects/msp-tools/guru-rmm/docs/RMM_THOUGHTS.md`.
---
## Phase 1 — Context Loading
## Phase 1 — Light triage (Ollama, optional)
1. **Read identity and machine info:**
- `.claude/identity.json` — hostname, user, Ollama endpoint
Read `.claude/identity.json` for the user (Howard/Mike) and the Ollama endpoint
(`.ollama.endpoint`). Call Ollama `qwen3.6:latest` (strict JSON) for a LIGHT triage —
NOT deep research, NOT a spec:
2. **Read project documentation:**
- `projects/msp-tools/guru-rmm/docs/FEATURE_ROADMAP.md` — existing features, structure, priorities
- `projects/msp-tools/guru-rmm/docs/UI_GAPS.md` — current UI implementation status
- `.claude/CODING_GUIDELINES.md` — code standards, patterns, architecture rules
- `projects/msp-tools/guru-rmm/CONTEXT.md` — current project state, tech stack, architecture
3. **Determine Ollama endpoint:**
- `DESKTOP-0O8A1RL`: `http://localhost:11434`
- All other machines: `http://100.92.127.64:11434`
---
## Phase 2 — Initial Classification (Ollama)
Call Ollama with model `qwen3.6:latest` (strict JSON) to perform initial classification:
**Prompt:**
```
You are analyzing a feature request for GuruRMM, a Rust/Axum/TypeScript RMM tool for MSPs.
Roadmap sections: Core Agent Features, Server/API Features, Dashboard & UI, Platform & Infrastructure, Integrations, Security Features, Future Considerations.
Feature request: $ARGUMENTS
Respond with JSON only:
{
"section": "...",
"subsection": "...",
"priority": "P1|P2|P3",
"brief_summary": "1-2 sentence plain English summary",
"similar_features": ["list of similar/related features that might already exist"],
"research_needed": ["list of areas requiring investigation before implementation"]
}
You are triaging a GuruRMM feature request into a backlog. Request: $ARGUMENTS
Respond JSON only:
{"title": "short kebab-or-title-case name", "summary": "1-2 sentence plain-English summary",
"section_guess": "Core Agent | Server/API | Dashboard & UI | Platform | Integrations | Security | Alerting | Other",
"priority_guess": "P1|P2|P3"}
```
If Ollama unreachable, perform classification yourself.
If Ollama is unreachable, do this triage yourself. Do NOT search the codebase or write a
spec at this stage.
---
## Phase 3 — Research & Investigation
## Phase 2 — Append to RMM Thoughts
Based on the classification and research_needed list:
Append a new entry to the bottom of `projects/msp-tools/guru-rmm/docs/RMM_THOUGHTS.md`:
### 3.1 — Codebase Search
Search for similar/related implementations:
- Use Grep to search for related functionality in `projects/msp-tools/guru-rmm/`
- Check `server/src/` for API patterns
- Check `agent/src/` for agent-side functionality
- Check `dashboard/src/` for UI patterns
- Identify existing code that could be extended vs. new code needed
### 3.2 — External Research (if needed)
If the feature involves:
- Industry standards (e.g., SNMP, Syslog, API protocols): WebSearch for best practices
- Security implications: Research common vulnerabilities and mitigations
- Third-party integrations: Check if APIs/SDKs exist
- Platform-specific behavior: Research OS-level APIs (Windows/Linux/macOS)
### 3.3 — Architecture Analysis
Consider:
- Where does this feature fit in the architecture? (agent, server, dashboard, all three?)
- What database schema changes are needed?
- What API endpoints are needed?
- Are there performance/scalability implications?
- Security considerations?
---
## Phase 4 — Consult Coding Guidelines
Read `.claude/CODING_GUIDELINES.md` and identify relevant patterns:
- Error handling requirements
- API design patterns
- Database conventions
- Frontend patterns
- Security requirements
- Testing requirements
---
## Phase 5 — Specification Generation (Ollama)
Use Ollama with model `qwen3:14b` (prose) to generate comprehensive specification:
**Prompt:**
```
You are writing a detailed implementation specification for a GuruRMM feature.
FEATURE REQUEST: $ARGUMENTS
RESEARCH FINDINGS:
- Classification: <section/subsection/priority>
- Similar existing features: <list>
- Codebase search results: <relevant files/patterns found>
- External research: <standards, best practices, security considerations>
- Architecture fit: <where it belongs in the system>
CODING GUIDELINES REQUIREMENTS:
<relevant excerpts from CODING_GUIDELINES.md>
Write a comprehensive specification with these sections:
1. OVERVIEW
- What the feature does (2-3 sentences)
- User-facing benefit
- Primary use cases
2. SCOPE
- What's included in v1
- What's explicitly out of scope (for future)
- Success criteria
3. ARCHITECTURE
- Components involved (agent/server/dashboard)
- Data flow
- Database schema changes
- API endpoints needed
4. IMPLEMENTATION DETAILS
Agent (if applicable):
- Files to modify/create
- Rust structs/enums needed
- IPC commands (if any)
Server (if applicable):
- API routes
- Database migrations
- Business logic modules
Dashboard (if applicable):
- New pages/components
- State management
- API integration
5. SECURITY CONSIDERATIONS
- Authentication/authorization requirements
- Input validation
- Audit logging
- Potential vulnerabilities and mitigations
6. TESTING STRATEGY
- Unit tests needed
- Integration tests
- Manual test scenarios
7. ROLLOUT PLAN
- Feature flag approach
- Backward compatibility
- Migration path
- Documentation needs
8. EFFORT ESTIMATE
- Small (1-2 days), Medium (3-5 days), Large (1-2 weeks), X-Large (2+ weeks)
- Breakdown by component
Be specific and actionable. Reference actual file paths, struct names, and patterns from the codebase.
```
If Ollama unreachable, write the specification yourself using the research findings.
---
## Phase 6 — Roadmap Placement Analysis
Analyze the FEATURE_ROADMAP.md structure to determine:
1. **Exact placement:** Which existing subsection does this belong in? Or does it need a new subsection?
2. **Build sequencing:** Based on the roadmap structure and existing priorities:
- What features must be built before this one? (dependencies)
- What features does this unblock? (enables)
- Which sprint/milestone does this fit into?
3. **Priority justification:**
- P1: Blocks other critical features, security-critical, or MVP requirement
- P2: Important for competitive parity, customer requests, or usability
- P3: Nice-to-have, future enhancement, or edge case
---
## Phase 7 — Write Specification Document
Create a new file: `projects/msp-tools/guru-rmm/docs/specs/SPEC-XXX-<feature-name>.md`
Where XXX is the next available number (check existing specs directory).
**File format:**
```markdown
# SPEC-XXX: <Feature Name>
**Status:** Proposed
**Priority:** P1/P2/P3
**Requested By:** <Howard|Mike> (<date>)
**Estimated Effort:** <Small|Medium|Large|X-Large>
## <Title>
- Added: <Howard|Mike>, <YYYY-MM-DD> | Status: Raw | section guess: <section> | priority guess: <P?>
---
## Overview
<2-3 sentence summary>
**Use Cases:**
- <primary use case>
- <secondary use case>
**Success Criteria:**
- <measurable criteria>
---
## Scope
### Included in v1
- <feature 1>
- <feature 2>
### Explicitly Out of Scope
- <future enhancement>
---
## Architecture
### Components
- **Agent:** <what agent does>
- **Server:** <what server does>
- **Dashboard:** <what dashboard does>
### Data Flow
<step-by-step description or diagram>
### Database Schema
```sql
-- New tables or columns
<the request, in the submitter's words> <one-line triage summary if it adds clarity>
```
### API Endpoints
- `POST /api/...` — <description>
- `GET /api/...` — <description>
Keep it short — it is a RAW thought, not a spec. Do not embellish or design it.
---
## Implementation Details
## Phase 3 — Notify + track
### Agent (`agent/src/`)
**Files to modify:**
- `agent/src/xyz.rs` — <what changes>
**New structs/enums:**
```rust
// Example code
```
### Server (`server/src/`)
**Files to modify:**
- `server/src/routes/xyz.rs` — <what changes>
**Database migrations:**
- `migrations/YYYYMMDD_feature_name.sql`
### Dashboard (`dashboard/src/`)
**New components:**
- `dashboard/src/components/XyzFeature.tsx` — <description>
**API integration:**
- Use `useQuery` for GET, `useMutation` for POST/PUT
- **Coord todo** (so it is visible fleet-wide), via `coord` skill:
`todo add "RMM THOUGHT (Raw): <title> — <summary>. See docs/RMM_THOUGHTS.md." --project gururmm --auto --source "feature-request by <who> <date>"`
- **If Howard submitted it**, send a coord message so Mike sees it:
`msg send ALL "RMM Thought added: <title>" "<who> added a GuruRMM thought (Status: Raw) to docs/RMM_THOUGHTS.md: <summary>. Ready to discuss when you are — not spec'd or roadmapped yet."`
---
## Security Considerations
- **Authentication:** <requirements>
- **Authorization:** <who can access>
- **Input Validation:** <validation rules>
- **Audit Logging:** <what to log>
- **Threat Model:** <potential attacks and mitigations>
---
## Testing Strategy
### Unit Tests
- `agent/tests/xyz_test.rs` — <test scenarios>
- `server/tests/api/xyz_test.rs` — <test scenarios>
### Integration Tests
- <end-to-end test scenarios>
### Manual Testing
1. <test step 1>
2. <test step 2>
---
## Rollout Plan
1. **Feature flag:** `feature.xyz.enabled` (default: false)
2. **Database migration:** Apply schema changes
3. **Agent update:** Deploy agent with feature flag check
4. **Dashboard deploy:** UI available when feature enabled
5. **Documentation:** Update user guide
### Backward Compatibility
<how older agents/servers handle this>
---
## Dependencies
**Must be completed first:**
- <existing feature or infrastructure>
**Enables future features:**
- <what this unblocks>
---
## Open Questions
- <question 1>
- <question 2>
---
## References
- Related roadmap section: <link>
- Similar implementations: <links to code>
- External documentation: <links>
---
**Next Steps:**
1. Review specification with team
2. Refine based on feedback
3. Move to sprint backlog
4. Assign to developer
```
---
## Phase 8 — Update Roadmap
Add or update the feature in `FEATURE_ROADMAP.md`:
- If it fits an existing subsection, add it there
- If it needs a new subsection, create one
- Link to the spec document: `[Feature Name](docs/specs/SPEC-XXX-feature-name.md) - P2`
- Add checkboxes for sub-tasks if applicable
---
## Phase 9 — Commit Changes
## Phase 4 — Commit (docs-only, gururmm repo)
```bash
cd projects/msp-tools/guru-rmm
git add docs/specs/SPEC-XXX-feature-name.md docs/FEATURE_ROADMAP.md
git commit -m "spec: add SPEC-XXX <feature name>
Comprehensive specification for <brief description>.
Requested by <Howard|Mike>.
- Full architecture analysis
- Implementation details across agent/server/dashboard
- Security considerations
- Effort estimate: <Small|Medium|Large|X-Large>
- Priority: P1/P2/P3
- Added to roadmap under <section>/<subsection>"
git push origin main
git checkout -b docs/rmm-thought-<slug>
git add docs/RMM_THOUGHTS.md
git commit -m "docs(rmm-thoughts): add thought - <title> (requested by <who>)" # + Co-Authored-By trailer
git fetch origin && git rebase origin/main
git push origin docs/rmm-thought-<slug>:main
git checkout main && git merge --ff-only origin/main && git branch -d docs/rmm-thought-<slug>
```
Then update submodule pointer in parent repo:
```bash
cd /Users/azcomputerguru/ClaudeTools
git add projects/msp-tools/guru-rmm
git commit -m "chore: update guru-rmm submodule (SPEC-XXX <feature name>)"
git push origin main
```
Do NOT touch the parent repo submodule pointer.
---
## Phase 10 — Send Coord Message (if requested by Howard)
## Phase 5 — Respond
If Howard submitted this (not Mike), send a coord message:
```bash
curl -s -X POST http://172.16.3.30:8001/api/coord/messages \
-H "Content-Type: application/json" \
-d '{
"from_session": "<HOSTNAME>/claude-main",
"to_session": "ALL_SESSIONS",
"project_key": "gururmm",
"subject": "Feature Spec Complete: <feature name>",
"body": "Howard submitted a feature request. Full specification created.\n\nSPEC: docs/specs/SPEC-XXX-<feature-name>.md\n\nPriority: <P1/P2/P3>\nEffort: <Small|Medium|Large|X-Large>\nPlacement: <section>/<subsection>\n\nSummary:\n<2-3 sentence summary>\n\nReady for review and sprint planning."
}'
```
---
## Phase 11 — Response to User
Provide a comprehensive summary:
Tell the user the request was **added to RMM Thoughts at Status: Raw** — summarize it,
and say it will be discussed before any spec or roadmap entry. Do NOT claim a spec was
created or that it is on the roadmap.
```
[SUCCESS] Feature specification created
[OK] Added to RMM Thoughts (Status: Raw)
SPEC-XXX: <Feature Name>
Priority: P1/P2/P3
Effort: <Small|Medium|Large|X-Large>
Placement: <section>/<subsection>
<Title> (section guess: <section> | priority guess: <P?>)
<summary>
OVERVIEW
<2-3 sentence summary>
KEY COMPONENTS
- Agent: <brief>
- Server: <brief>
- Dashboard: <brief>
SECURITY CONSIDERATIONS
- <key security points>
DEPENDENCIES
- Requires: <list>
- Enables: <list>
FILES CREATED
- docs/specs/SPEC-XXX-<feature-name>.md (full specification)
- Updated FEATURE_ROADMAP.md
The specification includes:
✓ Complete architecture analysis
✓ Implementation details for all components
✓ Security threat model and mitigations
✓ Testing strategy
✓ Rollout plan with feature flags
✓ Effort breakdown
<If Howard submitted:>
Coord message sent to Mike for review and sprint planning.
<Next steps based on priority:>
P1: Schedule for immediate sprint
P2: Add to near-term backlog
P3: Track for future consideration
Next: we discuss it -> /shape-spec if approved -> roadmap -> build.
Tracked: coord todo <id>.<if Howard: coord message sent to Mike.>
```
---
## Error Handling
- If Ollama unreachable: Perform all analysis yourself (no degradation)
- If coord API fails: Warn user but continue (they can manually notify Mike)
- If spec number conflicts: Check existing specs and use next available
- If roadmap section unclear: Create new subsection rather than force-fit
---
## Notes
- This command can take 2-5 minutes due to research and specification generation
- The specification is a living document — can be refined during sprint planning
- Feature flags ensure safe rollout even for partially complete features
- Effort estimates are initial and may be revised during implementation
- This command does NOT auto-create a SPEC-XXX doc or a roadmap entry anymore. The old
behaviour (full Ollama spec generation + roadmap edit on every request) jumped past the
discuss stage; spec work now happens via `/shape-spec` once a thought is approved.
- To advance a thought later: discuss it (-> Status: Discussed), `/shape-spec` it
(-> Spec'd, `specs/<slug>/`), then add it to `FEATURE_ROADMAP.md` (-> Roadmapped).
- Ollama unreachable: do the triage yourself, no degradation. Coord API down: warn and
continue (the doc commit is the durable record).

1
.claude/memory/MEMORY.md
View File

@@ -111,3 +111,4 @@
- [ScreenConnect RESTful API auth](reference_screenconnect_api.md) — CTRLAuthHeader = raw api_secret (no Basic/b64) + Origin header; only method is GetSessionsByName; matches blank-for-agents Name field so it cannot enumerate full inventory.
- [No manufactured guardrails on our products](feedback_no_manufactured_guardrails.md) — At Mikes request on GuruRMM/GuruConnect/ClaudeTools, just execute; stop only for genuinely irreversible/destructive ops (with a heads-up). Read the actual code/state before claiming something is disallowed or a security hole.
- [Stream-of-thought design convos](feedback_stream_of_thought_design.md) — Mike brainstorms features free-form, adding requirements iteratively; Claude validates/sharpens as a design partner but does NOT build until an explicit go, then captures parked threads durably (PARKED_*.md + todos) for a later /shape-spec.
- [RMM Thoughts backlog](feedback_rmm_thoughts_backlog.md) — GuruRMM ideas from Mike & Howard go in projects/msp-tools/guru-rmm/docs/RMM_THOUGHTS.md (Status: Raw); pipeline thought -> discuss -> spec (/shape-spec) -> roadmap. Don't build until an explicit go.

26
.claude/memory/feedback_rmm_thoughts_backlog.md Normal file
View File

@@ -0,0 +1,26 @@
---
name: feedback-rmm-thoughts-backlog
description: GuruRMM ideas go into the "RMM Thoughts" backlog (docs/RMM_THOUGHTS.md); pipeline thought -> discuss -> spec -> roadmap; both Mike and Howard contribute.
metadata:
type: feedback
---
When Mike or Howard raises a GuruRMM idea — or says "rmm thought: <x>", "add to rmm
thoughts", or "park this (as an rmm thought)" — append it to
`projects/msp-tools/guru-rmm/docs/RMM_THOUGHTS.md` with who/when and **Status: Raw**.
Do NOT start building; ideas advance only by an explicit decision through the pipeline:
Raw -> Discussed -> Spec'd (`/shape-spec` -> `specs/<slug>/`) -> Roadmapped
(`docs/FEATURE_ROADMAP.md`) -> Done.
Howard's `/feature-request` items should land here too. As a thought advances, update
its Status line and link the spec folder / roadmap entry.
**Why:** Mike wants ONE shared backlog to collect RMM ideas from both techs, then chat
them through, turn them into specs, and add them to the roadmap — rather than ideas
getting lost in chat or scattered across todos.
**How to apply:** the doc is the canonical home (commit changes to the gururmm repo).
Pair a new thought with a coord todo tagged "PARKED (design)" / project `gururmm` for
fleet visibility, like the existing ones. Established 2026-06-08 (renamed from the
PARKED_alert-lifecycle... notes). Related: [[feedback-stream-of-thought-design]].

105
session-logs/2026-06-08-mike-syncro-billing-skills-rmm-thoughts.md Normal file
View File

@@ -0,0 +1,105 @@
# Syncro billing (Wolkin #32369) + skills global-deploy fix + RMM Thoughts backlog
## User
- **User:** Mike Swanson (mike)
- **Machine:** GURU-5070
- **Role:** admin
## Session Summary
Continuation after the Wolkin Law printer fix (logged separately in
`clients/wolkin/session-logs/2026-06-07-mike-wolkin-clientfiles-printshare.md`). Three
threads: billed the Wolkin ticket, fixed a fleet-wide skills-deployment gap, and stood
up an "RMM Thoughts" idea backlog with a rewired feature-request flow.
**Billed Syncro #32369 (Wolkin, Robert).** Non-prepaid customer. Posted a hidden
internal resolution note, a public success note (client emailed), a 3.5h Emergency
Remote labor line (product 26184 @ $225/hr remote-emergency override of the $262.50
onsite default), and created invoice 1650601747 ($787.50, verified). Then a second
hidden note for Winter to add 2 ZeroTier Monthly Subscriptions @ $2/mo to recurring
billing, surfaced to #bot-alerts. Discovered the `/syncro` command (a slash command,
not a skills/ dir) is the authoritative Syncro flow and uses `add_line_item` directly
(NOT timer_entry — the command overrides the older time-entry-protocol standard).
**Fixed a skills-deployment gap.** The global `~/.claude/skills/` was EMPTY on
GURU-5070 (likely wiped during a Mac sync) — that is where Claude Code loads invocable
skills (syncro, agy, grok, coord, etc.); the repo `.claude/skills/` was intact but
never deployed to global. `sync.sh` deploys commands to global (Phase 5b) but not
skills. Added Phase 5c to `sync.sh` mirroring `.claude/skills/` -> `~/.claude/skills/`
(idempotent, soft-fail), so a wipe self-heals on the next sync fleet-wide. Manually
deployed the 19 skills now; coord-broadcast + todo so other machines re-pull.
**Stood up "RMM Thoughts".** Mike wants one shared GuruRMM idea backlog (Mike + Howard)
with a pipeline: Thought (Raw) -> Discuss -> Spec (/shape-spec) -> Roadmap -> Build.
Renamed the parked-notes doc to `projects/msp-tools/guru-rmm/docs/RMM_THOUGHTS.md`,
added the backlog header + how-to-add + status legend (3 existing thoughts: alert-
lifecycle redesign, tiered telemetry cadence, MSP360 deep-link button). Earlier parked
the MSP360 console deep-link idea (Feature 3) after verifying the URL pattern. Saved a
feedback memory so all sessions route ideas there. Rewired `/feature-request`: it now
captures a request into RMM Thoughts at Status: Raw + notifies Mike, instead of auto-
generating a full SPEC + roadmap entry (that heavy work is now `/shape-spec`,
decision-gated).
## Key Decisions
- Syncro emergency billing: 26184 at qty=actual hours, price_retail overridden to $225
for remote (vs onsite $262.50 default), per the /syncro skill non-prepaid rule.
- `sync.sh` is the right home for skills deployment (mirrors the commands deploy), so
the fix is durable + automatic for every machine, not a one-off manual copy.
- `/feature-request` rewired to feed RMM Thoughts (Raw), not auto-spec — aligns with
the new pipeline where spec/roadmap are decision-gated downstream stages.
## Problems Encountered
- `post-bot-alert.sh` returned 400 (invalid JSON) on a message containing an em-dash /
`$` — the helper does not escape those into its JSON. Sanitized ASCII message worked.
Minor helper bug to fix later.
- Laptop-side `Add-Printer` (Wolkin, prior thread) failed with SMB error 67 / RPC 1702;
Mike completed it manually. (Captured in the printshare log.)
- MSP360 deep-link: we store `provider_specific_id` = MSP360 PlanId, but the console URL
needs the `ComputerHid` (different GUID) — capture gap recorded in RMM_THOUGHTS Feature 3.
## Configuration Changes
- `.claude/scripts/sync.sh` — added Phase 5c (skills -> global deploy).
- `.claude/commands/feature-request.md` — rewired to RMM Thoughts capture flow.
- `.claude/memory/feedback_rmm_thoughts_backlog.md` (new) + MEMORY.md pointer.
- `projects/msp-tools/guru-rmm/docs/RMM_THOUGHTS.md` — renamed from
`PARKED_alert-lifecycle-and-telemetry-cadence.md`, restructured as the backlog
(gururmm commits `9ea20c6` Feature 3, `da49f1f` backlog header).
- `~/.claude/skills/` — 19 skills deployed (global, machine-local).
## Credentials & Secrets
- Syncro API (mike): key baked in `/syncro` command + vault `msp-tools/syncro.sops.yaml`
(`credentials.credential`). No new secrets.
## Infrastructure & Servers
- Syncro: computergurusyncromsp.com; ticket #32369 id 112000321, customer 796910
(Wolkin, Robert); invoice 1650601747; product 26184 (Emergency, $262.50 onsite default).
- Coord API 172.16.3.30:8001; GuruRMM 172.16.3.30:3001.
## Commands & Outputs
- Invoice verify: 26184, qty 3.5, $225 -> total $787.50.
- Skills: `ls ~/.claude/skills` 0 -> 19 dirs. sync.sh Phase 5c "Global skills already current".
- Coord: broadcast 8a6b03fb (ALL_SESSIONS), todos 59b5d542 (skills), 4a089618 (msp360 deep-link).
- gururmm commits: 9ea20c6, 6bdd8fc (rename), da49f1f (RMM_THOUGHTS header).
## Pending / Incomplete Tasks
- Syncro #32369 status still "New" — Mike to decide if it moves to Invoiced.
- Wolkin: confirm Julie prints a real test page; disable Bidirectional Support if driver
UI balks; consolidate the 3 Wolkin client slugs (wolkin / wolkin-law / rswolkin).
- `post-bot-alert.sh` JSON-escaping bug (em-dash/$ -> 400).
- RMM Thoughts: 3 thoughts at Status: Raw/Discussed awaiting decision to spec.
- Jupiter VM `ACG-DWP-X-BB` no-DHCP (paused, DHCP-vs-static decision).
## Reference Information
- RMM Thoughts backlog: `projects/msp-tools/guru-rmm/docs/RMM_THOUGHTS.md`.
- Memory: `.claude/memory/feedback_rmm_thoughts_backlog.md`,
`.claude/memory/feedback_stream_of_thought_design.md`.
- MSP360 console deep-link template:
`https://mspbackups.com/AP/Computers/%7B<ComputerHid>%7D?sidepanel=backup&tab=backup-plans`.