Enhance connected mode test suite and introduce VFS staleness fixtures

- Updated the connected mode test expansion plan, marking all todos as completed, including multi-step sequence tests and various phase implementations.
- Added a new plan for VFS staleness test fixtures, outlining the creation of a validation API, test helpers, and multiple staleness tests to improve detection of VFS event issues.
- Introduced new rules for the Atlas API and project file format specifications, enhancing the overall structure and documentation for better clarity and maintainability.

This update significantly improves testing coverage and addresses potential VFS synchronization issues.

.cursor/rules/atlas-api.mdc

@@ -8,7 +8,26 @@ globs:
   - "plugin/src/ApiContext.lua"
 ---
 
-# Rojo API & Communication
+# Atlas API & Communication
+
+> Atlas is a fork of Rojo. Many internal identifiers, API endpoints, and struct names still reference the original "Rojo" naming.
+
+## Quality Standard
+
+This is a production-grade synchronization system. The filesystem must represent a 1:1 copy of the Studio place. The core invariant:
+
+**Round-trip identity:** Syncback (or two-way sync) writes a directory tree. Building an rbxl from that directory tree and forward-syncing it back must produce a bit-identical instance tree -- same names, same classes, same properties, same hierarchy, same ref targets. Any deviation is a bug.
+
+Every audit item must be evaluated against this standard. A "works most of the time" finding is not acceptable. If there is ANY code path where an instance name, property, or hierarchy relationship can be lost, mangled, or silently altered through a syncback→rebuild cycle, flag it as critical.
+
+## Code Quality Standard
+
+We are building a maintainable codebase. During audits, watch for duplicated logic -- the same slugify/dedup/meta-update pattern copy-pasted across `change_processor.rs`, `api.rs`, `dir.rs`, `project.rs`, etc. If you find duplicated code that could be consolidated into a shared helper:
+
+- **Small refactor** (extracting a helper function, consolidating 2-3 call sites): flag it AND fix it as part of the audit.
+- **Major system rewrite** (restructuring data flow, changing function signatures across 10+ call sites, redesigning the snapshot pipeline): flag it clearly in a "Deferred Refactors" section at the bottom of the report. We will evaluate whether it's worth doing after the audit is complete.
+
+The goal is clean, DRY code that is easy to reason about and hard to get wrong. If the same "compute meta path, check if name needs slugify, upsert/remove name field" sequence appears in 3+ places, that's a refactor candidate.
 
 **Protocol Version:** 5 | Server/plugin MAJOR.MINOR must match
 
@@ -635,7 +654,7 @@ if serverInfo.protocolVersion ~= Config.protocolVersion then showError("Protocol
 
 ```bash
 # Server
-RUST_LOG=rojo::web=debug,rojo::serve_session=debug rojo serve
+RUST_LOG=rojo::web=debug,rojo::serve_session=debug atlas serve
 ```
 
 ```lua

.cursor/rules/atlas-project.mdc

@@ -9,7 +9,9 @@ globs:
   - "**/*.model.json"
 ---
 
-# Rojo Project File Format
+# Atlas Project File Format
+
+> Atlas is a fork of Rojo. Many internal identifiers, API endpoints, and struct names still reference the original "Rojo" naming.
 
 ## Project File Schema
 
@@ -21,7 +23,7 @@ globs:
 |-------|------|----------|-------------|
 | `name` | string | Yes* | Instance name (*optional if `default.project.json5`) |
 | `tree` | ProjectNode | Yes | Root instance tree structure |
-| `servePort` | number | No | Port for `rojo serve` (default: 34872) |
+| `servePort` | number | No | Port for `atlas serve` (default: 34872) |
 | `serveAddress` | string | No | Address to bind (default: `"127.0.0.1"`) |
 | `servePlaceIds` | number[] | No | Only allow sync to these place IDs |
 | `blockedPlaceIds` | number[] | No | Block sync to these place IDs |

.cursor/rules/atlas-syncback.mdc

@@ -5,11 +5,30 @@ globs:
   - "src/cli/syncback.rs"
 ---
 
-# Rojo Syncback Architecture
+# Atlas Syncback Architecture
+
+> Atlas is a fork of Rojo. Many internal identifiers, API endpoints, and struct names still reference the original "Rojo" naming.
+
+## Quality Standard
+
+This is a production-grade synchronization system. The filesystem must represent a 1:1 copy of the Studio place. The core invariant:
+
+**Round-trip identity:** Syncback (or two-way sync) writes a directory tree. Building an rbxl from that directory tree and forward-syncing it back must produce a bit-identical instance tree -- same names, same classes, same properties, same hierarchy, same ref targets. Any deviation is a bug.
+
+Every audit item must be evaluated against this standard. A "works most of the time" finding is not acceptable. If there is ANY code path where an instance name, property, or hierarchy relationship can be lost, mangled, or silently altered through a syncback→rebuild cycle, flag it as critical.
+
+## Code Quality Standard
+
+We are building a maintainable codebase. During audits, watch for duplicated logic -- the same slugify/dedup/meta-update pattern copy-pasted across `change_processor.rs`, `api.rs`, `dir.rs`, `project.rs`, etc. If you find duplicated code that could be consolidated into a shared helper:
+
+- **Small refactor** (extracting a helper function, consolidating 2-3 call sites): flag it AND fix it as part of the audit.
+- **Major system rewrite** (restructuring data flow, changing function signatures across 10+ call sites, redesigning the snapshot pipeline): flag it clearly in a "Deferred Refactors" section at the bottom of the report. We will evaluate whether it's worth doing after the audit is complete.
+
+The goal is clean, DRY code that is easy to reason about and hard to get wrong. If the same "compute meta path, check if name needs slugify, upsert/remove name field" sequence appears in 3+ places, that's a refactor candidate.
 
 **Syncback** is the reverse operation of building: it takes a Roblox binary file (rbxl/rbxm) and writes instances back to the filesystem according to project structure.
 
-**Entry point:** `rojo syncback <project> --input <file>`
+**Entry point:** `atlas syncback <project> --input <file>`
 
 ## Core Concept
 
@@ -280,9 +299,9 @@ fs_snapshot.removed_paths()
 
 1. **Collect paths** - Map every Ref → full instance path (e.g., `Workspace.Part1`)
 2. **Collect referents** - Find all properties that are Refs, store as (source_path, target_path)
-3. **Link referents** - After syncback, use Rojo's `$id` / `Rojo_Target_PropertyName` system to link instances
+3. **Link referents** - After syncback, use Atlas's `$id` / `Rojo_Target_PropertyName` system to link instances
 
-**Rojo linking system:**
+**Atlas linking system:**
 ```json
 {
     "id": "some-unique-id",
@@ -402,7 +421,7 @@ All errors collected and reported at end.
 2. Sending file to server
 3. Server runs syncback command
 
-**Two-way sync (experimental)** is different - see `rojo-api.mdc`.
+**Two-way sync (experimental)** is different - see `atlas-api.mdc`.
 
 ## Performance Considerations
 
@@ -416,7 +435,7 @@ All errors collected and reported at end.
 
 **Enable verbose logging:**
 ```bash
-RUST_LOG=rojo::syncback=debug rojo syncback project/ --input place.rbxl
+RUST_LOG=rojo::syncback=debug atlas syncback project/ --input place.rbxl
 ```
 
 **Shows:**
@@ -428,10 +447,10 @@ RUST_LOG=rojo::syncback=debug rojo syncback project/ --input place.rbxl
 **Test syncback:**
 ```bash
 # Syncback once
-rojo syncback project/ --input place.rbxl
+atlas syncback project/ --input place.rbxl
 
 # Build back to verify roundtrip
-rojo build project/ -o rebuilt.rbxl
+atlas build project/ -o rebuilt.rbxl
 
 # Compare
 diff place.rbxl rebuilt.rbxl

.cursor/rules/atlas.mdc

@@ -1,30 +1,49 @@
 ---
-description: "Essential Rojo context: architecture, contribution workflow, and code conventions for this project."
+description: "Essential Atlas context: architecture, contribution workflow, and code conventions for this project."
 alwaysApply: true
 ---
 
-# Rojo Project Guide
+# Atlas Project Guide
 
-## What is Rojo?
+> Atlas is a fork of Rojo. Many internal identifiers, API endpoints, and struct names still reference the original "Rojo" naming.
 
-Rojo bridges filesystem and Roblox Studio, enabling professional development tools (VS Code, Git) for Roblox. It's designed for power users building complex games, libraries, and plugins.
+## Quality Standard
+
+This is a production-grade synchronization system. The filesystem must represent a 1:1 copy of the Studio place. The core invariant:
+
+**Round-trip identity:** Syncback (or two-way sync) writes a directory tree. Building an rbxl from that directory tree and forward-syncing it back must produce a bit-identical instance tree -- same names, same classes, same properties, same hierarchy, same ref targets. Any deviation is a bug.
+
+Every audit item must be evaluated against this standard. A "works most of the time" finding is not acceptable. If there is ANY code path where an instance name, property, or hierarchy relationship can be lost, mangled, or silently altered through a syncback→rebuild cycle, flag it as critical.
+
+## Code Quality Standard
+
+We are building a maintainable codebase. During audits, watch for duplicated logic -- the same slugify/dedup/meta-update pattern copy-pasted across `change_processor.rs`, `api.rs`, `dir.rs`, `project.rs`, etc. If you find duplicated code that could be consolidated into a shared helper:
+
+- **Small refactor** (extracting a helper function, consolidating 2-3 call sites): flag it AND fix it as part of the audit.
+- **Major system rewrite** (restructuring data flow, changing function signatures across 10+ call sites, redesigning the snapshot pipeline): flag it clearly in a "Deferred Refactors" section at the bottom of the report. We will evaluate whether it's worth doing after the audit is complete.
+
+The goal is clean, DRY code that is easy to reason about and hard to get wrong. If the same "compute meta path, check if name needs slugify, upsert/remove name field" sequence appears in 3+ places, that's a refactor candidate.
+
+## What is Atlas?
+
+Atlas bridges filesystem and Roblox Studio, enabling professional development tools (VS Code, Git) for Roblox. It's designed for power users building complex games, libraries, and plugins.
 
 **Core capabilities:**
 - Filesystem-based development with live sync to Studio
 - Build/upload rbxl/rbxm files from command line
 - Syncback: pull instances from Roblox → filesystem (7.7.0+)
-- Two-way sync (plugin-based): live bidirectional sync during `rojo serve` sessions
+- Two-way sync (plugin-based): live bidirectional sync during `atlas serve` sessions
 
 ### Two-Way Sync Strategy
 
-**Long-term goal:** Plugin-based two-way sync will completely replace the `rojo syncback` CLI command, allowing syncback to be deprecated.
+**Long-term goal:** Plugin-based two-way sync will completely replace the `atlas syncback` CLI command, allowing syncback to be deprecated.
 
 **Current state:**
-- `rojo syncback` (CLI) is the **ground truth** for Roblox → filesystem syncing. It is battle-tested and handles edge cases reliably.
-- Plugin-based two-way sync (via `rojo serve` + the Studio plugin) is under active development to reach feature parity and match the resilience of CLI syncback.
+- `atlas syncback` (CLI) is the **ground truth** for Roblox → filesystem syncing. It is battle-tested and handles edge cases reliably.
+- Plugin-based two-way sync (via `atlas serve` + the Studio plugin) is under active development to reach feature parity and match the resilience of CLI syncback.
 - The bar for replacing syncback is high: plugin two-way sync must handle all the same scenarios (encoded names, nested projects, property conflicts, large trees, concurrent edits) just as reliably before syncback can be deprecated.
 
-**When working on two-way sync:** Plugin-based sync must produce **exactly the same filesystem output** that `rojo syncback` would give for the same input. Byte-for-byte identical files, identical directory structures, identical naming. If the plugin path produces different results, treat syncback as the correct reference unless there's an explicit, documented reason to diverge. Any divergence is a bug until proven otherwise.
+**When working on two-way sync:** Plugin-based sync must produce **exactly the same filesystem output** that `atlas syncback` would give for the same input. Byte-for-byte identical files, identical directory structures, identical naming. If the plugin path produces different results, treat syncback as the correct reference unless there's an explicit, documented reason to diverge. Any divergence is a bug until proven otherwise.
 
 ## Architecture Overview
 
@@ -36,7 +55,7 @@ Rojo bridges filesystem and Roblox Studio, enabling professional development too
 
 ### The Snapshot System
 
-Rojo's core innovation (`src/snapshot/`):
+Atlas's core innovation (`src/snapshot/`):
 1. **Snapshot Generation**: Pure function filesystem → instance tree
 2. **Diffing**: Generate minimal PatchSet
 3. **Patch Application**: Apply changes, return AppliedPatchSet for plugin
@@ -105,7 +124,7 @@ bash scripts/watch-build-plugin.sh  # macOS/Linux
 bash scripts/unit-test-plugin.sh
 ```
 
-**Install plugin:** `rojo plugin install`
+**Install plugin:** `atlas plugin install`
 
 ### Testing
 
@@ -138,7 +157,7 @@ Every PR updates `CHANGELOG.md`:
 ```markdown
 ## Unreleased
 
-* Made a change to Rojo ([#1234])
+* Made a change to Atlas ([#1234])
 
 [#1234]: https://github.com/UserGeneratedLLC/rojo/pull/1234
 ```