diff --git a/.claude/memory/MEMORY.md b/.claude/memory/MEMORY.md index baf0d92..0620aea 100644 --- a/.claude/memory/MEMORY.md +++ b/.claude/memory/MEMORY.md @@ -25,6 +25,7 @@ - [365 Remediation Tool](feedback_365_remediation_tool.md) - Always means Graph API app fabb3421, not CIPP - [Ollama Tier-0 Routing](feedback_ollama_tier0_routing.md) - Route drafts/summaries/classifications through Ollama (qwen3:14b). Mike designed ClaudeTools this way — not optional. - [Syncro Emergency Billing](feedback_syncro_emergency_billing.md) — Emergency = 1.5× multiplier, not additive. Branch by `customer.prepay_hours`: no-prepaid → `26184` at actual hrs; prepaid → `26118` at hrs×1.5. Never stack. Always set `price_retail`. +- [Identity precedence](feedback_identity_precedence.md) — Trust `.claude/identity.json` over the system-reminder `userEmail` hint when they disagree (shared-login machines). ## Machine - [ACG-5070 Workstation Setup](reference_workstation_setup.md) - Windows 11 Pro clean install 2026-03-30, replaced CachyOS. All tools installed. diff --git a/.claude/memory/feedback_identity_precedence.md b/.claude/memory/feedback_identity_precedence.md new file mode 100644 index 0000000..45a833d --- /dev/null +++ b/.claude/memory/feedback_identity_precedence.md @@ -0,0 +1,11 @@ +--- +name: identity.json beats userEmail hint +description: When .claude/identity.json and system-reminder userEmail disagree, trust identity.json — it's the per-machine source of truth +type: feedback +--- + +When the system-reminder context claims `userEmail = mike@azcomputerguru.com` but `.claude/identity.json` says `howard`, trust identity.json. The userEmail comes from global Claude Code config (Mike set up the login on both machines under his account); identity.json is the per-machine, gitignored file that records who actually sits at this keyboard. + +**Why:** On 2026-04-23 I addressed Howard as "Mike" because the claudeMd/userEmail context said so. Howard corrected me. The CLAUDE.md onboarding flow explicitly defines identity.json as the authoritative local identity. + +**How to apply:** At every session start, read `.claude/identity.json` FIRST (as CLAUDE.md step 1 requires) and greet from that file's `full_name`. Ignore the `# userEmail` context block for greeting purposes. If identity.json is missing, follow the first-machine bootstrap flow in CLAUDE.md — don't fall back to userEmail. diff --git a/clients/cascades-tucson/docs/migration/share-access-matrix-2026-04-23.md b/clients/cascades-tucson/docs/migration/share-access-matrix-2026-04-23.md index d546f82..e70431c 100644 --- a/clients/cascades-tucson/docs/migration/share-access-matrix-2026-04-23.md +++ b/clients/cascades-tucson/docs/migration/share-access-matrix-2026-04-23.md @@ -213,8 +213,7 @@ Agency placeholders ("Reliable Agency 1/2") are **not** being created as account These names show up on Synology but are not in John's current employee list. They'll be disabled when we retire the Synology file-share role: -- **Stephanie Devin** — "Accounting Assist", no longer in CSV. Confirm departed. -- **Amber M Lee, Ann Dery, Anna Pitzlin, Britney Thompson, Haris Durut, Monica RamirezRossette, Nela Durut-Azizi** — all former employees. +- **Amber M Lee, Ann Dery, Anna Pitzlin, Britney Thompson, Haris Durut, Monica RamirezRossette, Nela Durut-Azizi, Stephanie Devin** — all former employees. - **Tamra Johnson** (old alias — now `Tamra Matthews`) - **CasAdmin201** — prior-MSP admin account. Confirm with Meredith before deletion. - **Role accounts** — `Accounting`, `Dining Manager`, `Front Desk`, `mcnurse`, `memcarenurse`, `Memcare Receptionist`, `Nurse Tower`. These are shared logins that violate HIPAA unique-user-identification requirement. Replaced by the named-person accounts above. @@ -257,7 +256,6 @@ Tick each when answered: - [ ] **Shelby Trozzi** — OK with the narrower scope (no admin-full), keeping her as MC Director? - [ ] **Matt Brooks** — primary department: Maintenance or Resident Services (MC Receptionist)? - [ ] **Christine Nyanzunda** — Management as read-only OK, or does she need write? -- [ ] **Stephanie Devin** — confirm no longer employed (so we disable her Synology account) - [ ] **`Activities` folder** — confirm contents are Life Enrichment only (so we create CS-SERVER `LifeEnrichment` share with just LE team RW) - [ ] **`pacs` folder** — Howard verified 2026-04-23 it's empty on Synology. **Do we create a Clinical shared folder on CS-SERVER at all?** If clinical staff use ALIS for everything, retire the concept entirely (and strip Clinical from everyone's access lines above). If there's a future need, we create an empty `Clinical-PHI` share with the access list already proposed. - [ ] **`web` folder** — confirm we can retire entirely (DSM web station, not a business share) @@ -270,7 +268,26 @@ Tick each when answered: - **Create three new shares on CS-SERVER** — `LifeEnrichment`, `ALdocs`, `WebDocs` at `D:\Shares\`. Populate NTFS per this doc. - **Map the new shares** — LE workstations are net-new mappings (no drives today). Script the drive maps via GPO or logon script once per-user interviews close. - **Receptionist share — machine+user GPO/logon-script mapping** — drive letter (likely `S:`) should only map when the machine is a Tower reception PC (currently `RECEPTIONIST-PC`, and any future Tower-desk stations) AND the user is in a Tower receptionist role group. MC receptionist PC and Sales workstations must NOT get the drive auto-mapped even if the user also logs in elsewhere. -- **Retarget Synology Drive Client sync path** from `D:\Shares\Main` to `D:\Shares\Synology\` before Phase 4 share cutover. + +## Transition from Synology Drive Client to SMB mapped drives + +**Current state.** The Synology NAS (`cascadesDS`) two-way syncs its shares to CS-SERVER at `D:\Shares\Main\` via a Synology Drive Client running on CS-SERVER. That sync stays in place until Phase 4 cutover. Separately, some user workstations also have Synology Drive Client installed locally, pulling a cached copy of the shares to each PC — that's how those users access Management / SalesDept / Server / Public today. + +**Goal.** Replace each user's local Synology Drive Client with a standard SMB mapped drive (e.g. `\\CS-SERVER\Management`, backed by `D:\Shares\Main\Management`). Because CS-SERVER's copy is kept current by the NAS-side sync, users see the same files via the mapped drive as they did via Synology Drive Client — no data move, just a different access path. + +**Prerequisite.** NTFS permissions on each `D:\Shares\Main\` folder must match this access matrix **before** drives are mapped on a user's PC. Otherwise users will see the folder but hit access-denied on files. + +**Rollout per user:** + +1. Create / populate that user's `SG-*-RW` group memberships per this matrix. +2. Map their drives via GPO Preferences (or logon script) based on those group memberships. +3. Have the user sign in, open each mapped drive, confirm read-and-write works where expected. +4. Uninstall Synology Drive Client from the PC. Delete the local cached folder once confirmed empty of unsynced changes. +5. Log the change in the session log for that day. + +**At Phase 4 cutover** the sync direction breaks: CS-SERVER becomes authoritative, the Synology moves to read-only, then to a backup target. Mapped drives already point at CS-SERVER so no user-side change is needed at cutover. + +**Do not retarget the CS-SERVER Synology Drive Client sync path.** It stays at `D:\Shares\Main\` for the duration. An earlier version of this doc proposed moving it to `D:\Shares\Synology\` — that plan is scrapped because it would break the current user-side Synology Drive Client sync for the users still on it. ## Next step — per-user interviews @@ -290,8 +307,9 @@ For Howard's reference during setup. Reviewers can skip this section. Two path conventions on CS-SERVER's D: drive: -- **`D:\Shares\Synology\\`** — two-way synced with cascadesDS via Synology Drive Client. Use this for any share that needs to exist on both the Synology NAS and CS-SERVER during the Phase 4 overlap window: Management, SalesDept, Server, Public, homes, and any others Meredith wants kept in sync. -- **`D:\Shares\\`** — CS-SERVER-local only, no Synology sync. Use this for shares that don't exist on Synology today or don't need a Synology copy: Culinary, IT, Receptionist, directoryshare. +- **`D:\Shares\Main\\`** — two-way synced with cascadesDS via Synology Drive Client running on CS-SERVER. Use this for any share that needs to exist on both the Synology NAS and CS-SERVER during the Phase 4 overlap window: Management, SalesDept, Server, Public, and any others Meredith wants kept in sync. **This is the existing sync target — do not retarget.** +- **`D:\Shares\\`** — CS-SERVER-local only, no Synology sync. Use this for shares that don't exist on Synology today or don't need a Synology copy: Culinary, IT, Receptionist, directoryshare, LifeEnrichment, ALdocs, WebDocs. +- **`D:\Homes\\`** — per-user folder-redirection share. Exposed as `\\CS-SERVER\homes`. Not under either shares tree; not Synology-synced. SMB share names stay flat (`\\CS-SERVER\Management`, `\\CS-SERVER\Culinary`) — users never see the path difference. Only the NTFS path under the hood changes. @@ -299,11 +317,11 @@ Shares to create/update on CS-SERVER at this path convention: | SMB share | CS-SERVER path | Synced with Synology? | |---|---|---| -| Management | `D:\Shares\Synology\Management` | yes | -| SalesDept | `D:\Shares\Synology\SalesDept` | yes | -| Server | `D:\Shares\Synology\Server` | yes | -| Public | `D:\Shares\Synology\Public` | yes | -| homes | `D:\Shares\Synology\homes` | yes | +| Management | `D:\Shares\Main\Management` | yes | +| SalesDept | `D:\Shares\Main\SalesDept` | yes | +| Server | `D:\Shares\Main\Server` | yes | +| Public | `D:\Shares\Main\Public` | yes | +| homes | `D:\Homes` | **no** (local, folder-redirection target) | | LifeEnrichment | `D:\Shares\LifeEnrichment` | **no** (CS-SERVER local, new) | | ALdocs | `D:\Shares\ALdocs` | **no** (CS-SERVER local, new) | | WebDocs | `D:\Shares\WebDocs` | **no** (CS-SERVER local, new) | @@ -314,9 +332,9 @@ Shares to create/update on CS-SERVER at this path convention: | IT | `D:\Shares\IT` | **no** | | Sandra Fish Archive | `D:\Shares\Archive\Former-Director-Sandra-Fish` | **no** — Meredith-only, archived | -The existing Synology Drive Client sync target on CS-SERVER today is `D:\Shares\Main` (per `docs/servers/cs-server.md`) — that will be retargeted to `D:\Shares\Synology\` before Phase 4 NTFS permissions go on, so the path convention matches this doc. +The existing Synology Drive Client sync target on CS-SERVER is `D:\Shares\Main\` (per `docs/servers/cs-server.md`). **It stays there for the duration of the Phase 4 overlap.** An earlier draft of this doc proposed retargeting to `D:\Shares\Synology\` — that plan is scrapped; users currently rely on `D:\Shares\Main\` and a retarget would break their sync. -`scripts/phase2-file-shares.ps1` will need its `$DestRoot` + per-share `Path` values updated to match. +`scripts/phase2-file-shares.ps1` will need its `$DestRoot` + per-share `Path` values updated to match (`D:\Shares\Main\` for synced shares, `D:\Shares\` for local-only). ---