claude-code - 💡(How to fix) Fix [BUG] CoWork Deleted All Content from a Cowork Workspace

I see a new file (`Investigate Deleted Folders.txt`) and small updates to a couple of others. Reading the new and updated content now.Yes — `Investigate Deleted Folders.txt` adds critical information. Reading it changed three things for me:

1. **A past file-deletion incident** that was never resolved — files you placed manually in the workspace folder went missing during a prior session.
2. **An explicit commitment** I (prior Claude) made about your workspace folder.
3. **Confirmation that memory _was_ saved at the end of that prior session** — but it didn't carry forward to this new project/space, which explains why I'm starting empty today.

Let me record everything to durable memory now so we don't keep losing context.TL/DR: The new file (`Investigate Deleted Folders.txt`) added three important things to memory that I would not have known: a past workspace-folder file-loss incident, an explicit no-delete commitment my prior self made to you, and confirmation that the lost `bg3_unpacked_mods_analysis.md` memory file existed before the project switch wiped it. I've now written nine memory files to the persistent memory directory so this context survives future restarts. Below is what I learned and what I propose next.

## What the new transcript added that I didn't have before

**The workspace deletion incident (high-priority context).** In a prior session, files you had **manually placed** in the workspace folder went missing. You flagged it explicitly: *"I placed folders directly into the workspace and they are now gone. That seems like a deliberate deletion to me. Is there any possibility that Claude deleted the contents of the workspace?"* My prior self responded: *"I cannot rule out that a previous Claude session deleted or overwrote files in your workspace... I will be deliberate about saving only to this workspace — never deleting anything here without your explicit instruction."* That commitment is now a permanent feedback memory.

**Confirmation that prior memory was real.** The transcript shows that before you restarted in this new project, the prior Claude saved memory files including `bg3_unpacked_mods_analysis.md`, plus a project-status file. None of those carried into this project's memory space — which finally explains *why* I started today with nothing. That's now also in a feedback memory so I'll always check both the memory directory AND the workspace `.md` files at the start of a session.

**Origin of the workspace `.md` reference files.** `BG3 Modding Resources & Links.md` and `BG3 Modding Technical Reference.md` were written by the prior Claude during the recovery session — they were a deliberate redundancy to survive future memory loss. That was good practice and I'm now formalizing it as a rule (save important findings to both surfaces, not just memory).

## Memory now persisted (9 files)

Saved at `C:\Users\Alan\AppData\Roaming\Claude\...\memory\`:

- **`MEMORY.md`** — index of all memory files
- **`user_profile.md`** — your role, Opus 4.7 in Cowork mode, this is your third project on this work
- **`project_tooltip_mod.md`** — the body-type/race compatibility mod goal, design approach, current status
- **`project_obsc_mods_analysis.md`** — preliminary body-type table for the 4 OBSC mods
- **`project_new_reference_material.md`** — BetterTooltips, TooltipExtras, Shared/ — what each is and what to do with it
- **`feedback_workspace_safety.md`** — the no-delete rule
- **`feedback_persistence.md`** — save important work to BOTH memory and workspace
- **`feedback_citations.md`** — your sourcing/quoting/citing standards
- **`reference_paths.md`** — all the relevant paths on your machine and inside Claude
- **`reference_bg3_wiki.md`** — the Community Library wiki and what's already been extracted

## Where we are vs. where we left off

We are essentially back at the point the prior session was cut off, with three pieces of new reference material added (BetterTooltips, TooltipExtras, Shared/). The remaining work for the tooltip mod is:

1. Read `Public/[Mod]/RootTemplates/_merged.lsf.lsx` for each of the four OBSC mods → authoritative `EquipmentRace` GUIDs.
2. Read `visuals.lsx` for each → mesh-per-slot definitions.
3. Build the GUID → race/body-type-label map by reading the equivalent file in `Shared/Public/Shared/RootTemplates/_merged.lsf.lsx`.
4. Inspect `TooltipExtras/TooltipExtraTexts.lsx` to see if Larian's data-driven tooltip system supports per-item entries we can target.
5. Inspect the relevant tooltip XAML in `Shared/Public/Shared/GUI/` to understand the override surface.
6. Decide implementation surface (XAML override vs. TooltipExtraTexts vs. Stats-only) and write the mod.

## Question — where would you like me to dig first?Setting up the parallel research now. Three subagents, three threads.You are researching a BG3 (Baldur's Gate 3) tooltip mod. The goal: read armor/clothing mod RootTemplates to extract `EquipmentRace` GUIDs, then build the authoritative GUID → race/body-type-label map by reading the unpacked base-game `Shared` data. Report findings with exact citations (file path + line numbers). Do not write code; this is research only.

## Background you need
- BG3 has 4 body types per race: BT1 (Feminine Regular), BT2 (Masculine Regular), BT3 (Feminine Strong), BT4 (Masculine Strong). Encoded as BodyShape (uint8: 0=Regular, 1=Strong) + BodyType (uint8: 0=Masculine, 1=Feminine).
- Each player Root Template has an `EquipmentRace` GUID attribute pointing to a mesh-set used for equipped items.
- Armor mods provide visual data for specific EquipmentRace GUIDs. Items with no visual for a given EquipmentRace will clip / be invisible on that body.
- The tooltip mod's job is to read an item's supported EquipmentRace GUIDs and display the corresponding race/body-type labels.

## Files to read

**OBSC mod folders** (in `C:\Users\Alan\OneDrive\Claude Projects\BG3 Mods\`):
- `OBSC_Ataraxia_Revamped\Public\OBSC_Ataraxia_Revamped\RootTemplates\_merged.lsf.lsx`
- `OBSC_Ataraxia_Revamped\Public\OBSC_Ataraxia_Revamped\Content\Assets\Characters\[PAK]_Armor\visuals.lsf.lsx` (also `visuals.lsx` if present)
- `OBSC_Indiana_Jones\Public\OBSC_Indiana_Jones\RootTemplates\_merged.lsf.lsx` (also `OBSC_Indiana_Jones.lsf.lsx.lsf.lsx`)
- `OBSC_Indiana_Jones\Public\OBSC_Indiana_Jones\Content\Assets\Characters\[PAK]_Armor\visuals.lsf.lsx`
- `OBSC_Lovely_Bloom_Dress\Public\OBSC_Lovely_Bloom_Dress\RootTemplates\_merged.lsf.lsx`
- `OBSC_Lovely_Bloom_Dress\Public\OBSC_Lovely_Bloom_Dress\Content\Assets\Characters\[PAK]_Armor\visuals.lsf.lsx`
- `OBSC_Moonlit_Minstrel\Public\OBSC_Moonlit_Minstrel\RootTemplates\_merged.lsf.lsx`
- `OBSC_Moonlit_Minstrel\Public\OBSC_Moonlit_Minstrel\Content\Assets\Characters\[PAK]_Armor\visuals.lsf.lsx`

Use Glob to confirm exact filenames in each folder before reading; some folders may have `.lsf.lsx` or `.lsx` or `_merged.lsf.lsx.lsf.lsx` variants.

**Shared base-game data** (unpacked Shared.pak, in `C:\Users\Alan\OneDrive\Claude Projects\BG3 Mods\Shared\`):
- Look for player Root Template definitions (likely under `Shared\Public\Shared\RootTemplates\` or `Shared\Public\SharedDev\RootTemplates\` or `Shared\Mods\Shared\RootTemplates\`). These contain the canonical player races with `EquipmentRace` GUIDs and `Name` strings like `Elves_Female_ShadarKai_Player_Strong`.
- Use Glob and Grep to find files containing `EquipmentRace` attribute definitions.

## What to extract and report

1. **Per-item EquipmentRace GUIDs for each OBSC mod**: For each mod, list each item's MapKey/Name and its EquipmentRace GUID attribute(s). If an item has no EquipmentRace attribute, note that (it likely inherits from ParentTemplateId).
2. **Authoritative GUID → race/body-type-label map**: From the Shared root templates, extract every player Root Template entry and produce a table mapping `EquipmentRace` GUID → race + body-type label. Each Root Template should have both a `Name` (e.g., "Elves_Female_ShadarKai_Player_Strong") and an `EquipmentRace` GUID — list every one you can find.
3. **Comparison to GR2 filename heuristic**: For each of the 4 OBSC mods, state whether the EquipmentRace GUIDs confirm or contradict the heuristic body-type table:
   - OBSC_Ataraxia_Revamped: BT1 (HUM_F) + BT3 (HUM_FS); Tiefling heels BT1+BT3 only
   - OBSC_Indiana_Jones: BT2 (HUM_M) only
   - OBSC_Lovely_Bloom_Dress: BT1 + BT3; Tiefling heels BT1+BT3
   - OBSC_Moonlit_Minstrel: BT1 only

## Report format
- Top section: **Findings summary** (3-5 sentences)
- Section per topic above with **exact file paths** and **line numbers** for each cited fact
- If you can't find something, say so explicitly — never guess. Alan's strict rule: "Never guess or hallucinate when reporting facts."
- Keep the report dense — no preamble, no postscript.You are researching a BG3 (Baldur's Gate 3) tooltip mod. The goal: determine whether Larian's data-driven `TooltipExtraTexts` system is a viable authoring path for displaying body-type/race compatibility info in armor/clothing item tooltips. Report findings with exact citations (file path + line numbers). Do not write code; this is research only.

## Background you need
- BG3 mod-authors have two main ways to add content to item tooltips: (a) override Larian's tooltip XAML files (heavy, fragile, requires ImpUI as a dependency) or (b) use Larian's data-driven `TooltipExtraTexts` system if it supports the kind of per-item entries we need.
- The mod we're building wants to display each armor/clothing item's supported body types (BT1/BT2/BT3/BT4) and races.

## Files to read
Both files are small. Read each in full:
- `C:\Users\Alan\OneDrive\Claude Projects\BG3 Mods\TooltipExtras\TooltipExtraTexts.lsx`
- `C:\Users\Alan\OneDrive\Claude Projects\BG3 Mods\TooltipExtras\TooltipUpcastDescriptions.lsx`

## What to extract and report

1. **File schema**: What is the LSX root region? What node hierarchy? Identify all distinct node IDs and attribute IDs used. Quote representative XML snippets with line numbers.
2. **Granularity**: Are entries keyed per-item / per-stat / per-template / per-tag / per-spell? Is there a `MapKey` field that links each entry to an item/template UUID, a stat name, or something else?
3. **What kinds of text can each entry hold?** Looking at the attributes, is it just localization handles, a category enum, a condition, or something richer?
4. **Examples**: Pick 2-3 concrete entries from `TooltipExtraTexts.lsx` and walk through what each one does — including the `MapKey` value and what it appears to link to.
5. **TooltipUpcastDescriptions.lsx**: This is likely a smaller specialized variant. Briefly describe how it differs from `TooltipExtraTexts.lsx`.
6. **Viability assessment for our use case**: Based on the schema, can a mod use this system to attach **per-item or per-template** body-type compatibility text to armor/clothing items? Or is the system limited to (e.g.) per-spell-tag or per-stat tooltip extras? If it's per-item, what would a mod-author entry look like?
7. **Unknowns**: Anything in the schema you can't interpret with confidence — flag explicitly. Don't guess.

## Report format
- Top section: **Findings summary** (3-5 sentences) with explicit yes/no/maybe verdict on whether this system fits our mod.
- Section per topic above with **exact file paths** and **line numbers**.
- Quote XML snippets exactly. Alan's strict rule: "Never guess or hallucinate when reporting facts."
- Keep the report dense — no preamble, no postscript.You are researching a BG3 (Baldur's Gate 3) tooltip mod. The goal: find Larian's base-game tooltip XAML files inside the unpacked Shared.pak data, identify the resource dictionaries and item-tooltip templates, and map the override surface that a mod would need to extend to add body-type compatibility info to armor/clothing tooltips. Report findings with exact citations (file path + line numbers). Do not write code; this is research only.

## Background you need
- BG3's UI uses WPF/NoesisGUI XAML for tooltips. Mods can override Larian's resource dictionaries to add or change tooltip content.
- A third-party mod called "Better Tooltips" (located at `C:\Users\Alan\OneDrive\Claude Projects\BG3 Mods\BetterTooltips_bc1081b4-e2a9-ce49-8b60-6f64b7eecce4\Mods\BetterTooltips_bc1081b4-e2a9-ce49-8b60-6f64b7eecce4\GUI\Library\Lib_Keyboard.xaml`) overrides Larian's `EquipmentSlotTypeStyle` (around line 7656 of that file) and uses WPF `DataTrigger`s bound to data-context properties like `EquipmentSlotType`, `UseType`, `ItemType`, `SubtypeId`, `Rarity`, `Name`. We want to know what Larian's base versions of those resources look like so we know the override surface.
- Our mod will need to display each armor/clothing item's supported body types in its tooltip.

## Files and locations to search
Start in `C:\Users\Alan\OneDrive\Claude Projects\BG3 Mods\Shared\`. The likely locations are:
- `Shared\Public\Shared\GUI\` and subfolders
- `Shared\Public\SharedDev\GUI\` and subfolders
- `Shared\Mods\Shared\GUI\` and subfolders
- `Shared\Mods\SharedDev\GUI\` and subfolders

Use Glob to find `*.xaml` files; use Grep to find files containing tooltip-related keywords:
- "TooltipStyle" / "ItemTooltip" / "TooltipTemplate"
- "EquipmentSlotType" / "ArmorClass" / "TooltipTitle" / "TooltipSubtitle"
- "Tooltip" (broad)

## What to extract and report

1. **File inventory**: List every XAML file in the Shared unpack that has tooltip-related content. Note the size (rough line count) and the resource categories each file appears to define.
2. **Item-tooltip Style/Template**: Find the file(s) that define the **item tooltip** specifically (the tooltip shown for armor, weapons, etc.). Quote the opening of the relevant Style or DataTemplate, with file path + line numbers.
3. **Data-context properties bound by the item tooltip**: List the properties Larian's base item-tooltip references — e.g., `EquipmentSlotType`, `ItemType`, `UseType`, `ArmorClass`, `Rarity`, `Damage`, etc. For each property, give one example line citation.
4. **The `EquipmentSlotTypeStyle` resource (or equivalent)**: Locate Larian's base version of the resource that BetterTooltips overrides. Quote the opening of the Style and a few representative DataTriggers — including any existing `Cloak`, `Helmet`, `Boots`, `Gloves`, etc. cases. Note its file path and line numbers.
5. **Override surface assessment**: Based on what you found, briefly describe (a) what file(s) a mod would have to ship to add a "body-type compatibility" section to the item tooltip, (b) what data-context property the mod would have to bind to (or invent), and (c) whether this would require ImpUI or another framework.
6. **Unknowns**: Anything you can't determine from the files — flag explicitly. Don't guess.

## Report format
- Top section: **Findings summary** (4-6 sentences) including the file path of the most important tooltip XAML.
- Section per topic above with **exact file paths** and **line numbers**.
- Quote XML snippets exactly. Alan's strict rule: "Never guess or hallucinate when reporting facts."
- Keep the report dense — no preamble, no postscript.