hakowork/rojo
3
0
Fork 0
mirror of https://github.com/rojo-rbx/rojo.git synced 2026-10-23 05:51:39 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update reflection database and enhance deduplication processes

Browse source 
- Updated the `rbx-dom` subproject to the latest commit for improved functionality.
- Enhanced the `/audit` command documentation to emphasize the importance of entering Plan mode before executing any actions.
- Improved the `atlas-dedup.mdc` file by adding details on user-initiated renames and ensuring ref path integrity during deduplication.
- Cleared out deprecated material color entries in `allValues.json` for better clarity.
- Updated `database.json` to reflect new properties and classes, including `AssetQualityService` and `BaseCoreGuiConfiguration`.
- Introduced new scripts for updating the reflection database, streamlining the process for generating necessary files.

These changes improve the overall functionality and maintainability of the project, ensuring better handling of deduplication and reflection updates.
This commit is contained in:
Joe 2026-02-17 07:12:00 -06:00
parent 85787f3452
commit 0afe6be441
12 changed files with 3220 additions and 283 deletions
Download patch file Download diff file Expand all files Collapse all files

4
.cursor/commands/audit.md
View file

@ -1,8 +1,10 @@
# /audit - Production-Grade Sync Feature Audit
**IMMEDIATE ACTION:** Before reading any files, running any commands, or performing any analysis, you MUST call `SwitchMode` with `target_mode_id: "plan"`. Do not proceed with any other step until you are in Plan mode. This is non-negotiable.
**Mode:** This command runs in **Plan mode** (read-only). It does NOT directly apply code changes. The deliverable is a `.cursor/plans/*.plan.md` file containing every approved fix, ready to be executed in a subsequent Agent-mode session.
**Workflow:** Analyze -> Report -> Quiz user on each fix -> Write plan file.
**Workflow:** Switch to Plan mode -> Analyze -> Report -> Quiz user on each fix -> Write plan file.
## Prerequisites

13
.cursor/rules/atlas-dedup.mdc
View file

@ -403,6 +403,15 @@ After successful dedup rename (e.g., `Foo~1` → `Foo`):
5. Updates the index: both path keys and filesystem paths
6. Suppresses VFS events for each file write
### Ref Path Updates After User-Initiated Rename
User-initiated renames (via the plugin's two-way sync) also update `Rojo_Ref_*` paths. The flow:
1. `old_ref_path` is captured BEFORE the rename (line ~1268, `ref_target_path_from_tree`)
2. Rename handler sets `new_ref_segment` to the new filesystem name (directory rename line ~1350, file rename line ~1512)
3. After rename handling, `update_ref_paths_after_rename(old_ref_path, new_ref_path)` is called (line ~1812) to update all meta/model files containing refs to the renamed instance
This ensures both dedup-triggered and user-initiated renames maintain ref path integrity.
### Metadata Consistency
After dedup rename, the survivor's metadata must be updated:
@ -487,9 +496,9 @@ The greedy assignment may produce suboptimal pairing in rare ambiguous groups. A
Phase 2e from the original plan: optional cache mapping `parent_ref → (children_list_hash, match_assignments)` to avoid re-running matching when children haven't changed. Optimization only, not needed for correctness.
### Stale Ref Paths After Rename
### ~~Stale Ref Paths After Rename~~ (Resolved)
When a Ref target is renamed, the stored `Rojo_Ref_*` path becomes stale. During two-way sync, `update_ref_paths_after_rename` handles this for dedup-triggered renames. However, user-initiated renames via the plugin do NOT automatically update ref paths in meta files. The path remains stale until the next full syncback. This is a known round-trip violation.
Both dedup-triggered renames and user-initiated renames now update `Rojo_Ref_*` paths automatically. See "Ref Path Updates" in the Integration Point 1 section for details.
---