RepoDitor v0.2.0 — Faster, Safer, and More Game-Aware

RepoDitor v0.2.0 — Faster, Safer, and More Game-Aware

RepoDitor v0.2.0 is a substantial update over v0.1.1 focused on packaged-app performance, evidence-backed editing, presentation caching, safer mutation boundaries, a more polished desktop experience, and much stronger contributor documentation.

This release keeps RepoDitor's core design intact: save parsing, validation, mutation, encryption, and persistence remain owned by the bundled Python backend, while the Electron/React desktop layer works through narrow typed operations.

Important

Unsigned Windows build

This release is currently unsigned while RepoDitor's code-signing approval is pending. Windows SmartScreen may display an Unknown Publisher or unrecognized-app warning.

Download RepoDitor only from this GitHub repository and verify the published SHA-256 checksum before running the installer.

---

Highlights

• Faster packaged save opening with the Python sidecar moved from PyInstaller --onefile to --onedir.
• Very fast same-session save reopening after a fresh fingerprint-confirmed open.
• Evidence-backed Item Recharge with validated installed-game capability data.
• Persistent, source-validated upgrade artwork caching across RepoDitor restarts.
• Expanded Cosmetics catalog with installed metadata, local icons, filters, sorting, and eligible single-item unlocks.
• Improved Players, Upgrades, Run, Items, Cosmetics, Maps, pending-change, and loading UX.
• Stronger game-running and mutation representation checks before save persistence.
• A clearer open-source/local-data/security model in public documentation.
• Much broader Python, Electron, React, packaged-E2E, cache, installer, and safety regression coverage.
• Repository-wide source documentation for future contributors, including production Python package __init__.py boundaries and frontend/Electron ownership notes.

---

What's New

Packaged performance improvements

RepoDitor's packaged Python backend now uses a PyInstaller onedir distribution instead of onefile.

RepoDitor intentionally uses short-lived Python commands rather than a persistent Python daemon. With onefile, those short-lived commands repeatedly paid PyInstaller extraction/bootstrap overhead. The new onedir layout keeps the same command boundary while reducing that startup cost.

The packaged runtime executable remains available through RepoDitor's fixed backend resource path, and the installer continues to bundle everything required for normal use.

Save-opening behavior

Save opening now distinguishes between:

• the fresh authoritative save read, and
• later editor-entry preparation or presentation work.

RepoDitor does not fake progress percentages for work that has no trustworthy progress count.

A same-session editor snapshot may be reused only after a new explicit open confirms that the save's source fingerprint is unchanged. A successful write invalidates that reusable editor-entry state.

Decoded save JSON is not persistently cached.

Observed packaged timings

Maintainer/package-smoke measurements during this release cycle included approximately:

launch   ≈ 2.8 s
open     ≈ 10.2 s
reopen   ≈ 0.44 s
run.get  ≈ 0.30 s

These are observational development/release measurements, not hard performance guarantees. Actual timings vary by hardware, disk state, antivirus activity, operating-system scheduling, and game installation state.

---

Item Recharge is now evidence-backed

Recharge / Refill to Full has been significantly strengthened.

RepoDitor no longer treats the mere presence of a save value as sufficient proof that an item type is safely rechargeable.

The current flow uses authoritative installed-game metadata to determine Recharge capability and keeps the result tied to the game installation evidence from which it was discovered.

Session evidence reuse

The first authoritative Items/Advanced discovery can produce reusable Recharge evidence.

Electron main may retain that backend-produced evidence for the current RepoDitor session, but Electron possession of the evidence is not authorization.

Before a later Recharge write can reuse it, Python independently verifies relevant facts such as:

• evidence format/version;
• validated game build;
• installation identity;
• relevant Unity metadata source identities;
• exact requested item coverage;
• backend-derived capability values.

If the evidence is missing, stale, malformed, incomplete, unsupported, or no longer matches the current installation, RepoDitor falls back to the full authoritative discovery path.

UNKNOWN and NOT_RECHARGEABLE never become permission to mutate.

Measured Recharge improvement

Profiling during development found that the old Recharge path spent roughly 6.47 seconds in repeated installed Unity metadata discovery, with a total operation around 6.96 seconds.

With valid primed evidence, representative measurements were approximately:

before: ~6.96 s
after:  ~0.48 s

or about a 93% reduction in the tested primed path.

The safe-save pipeline itself was not weakened or reordered to achieve this.

---

Richer Items workspace

The Items editor has grown beyond the earlier basic instance view.

Current functionality includes:

• discovered item-instance browsing;
• search;
• filtering;
• sorting;
• local item icon presentation when validated data is available;
• evidence-backed Recharge eligibility;
• exact-instance pending Recharge changes;
• clear unsupported/unknown behavior rather than guessing mutation semantics.

RepoDitor still intentionally does not provide generic arbitrary item mutation.

Numeric charge editing, unsupported battery-upgrade writes, arbitrary purchase mutations, and item add/delete/duplicate operations remain outside the supported mutation model unless their semantics are independently established.

---

Expanded Cosmetics / MetaSave support

Cosmetics now has a significantly richer catalog experience.

When compatible installed metadata is available, RepoDitor can present game-owned information such as:

• display names;
• cosmetic type;
• rarity;
• optional local icons;
• ownership state;
• saved-preset context.

The catalog now supports:

• search;
• ownership filtering;
• type filtering;
• sorting;
• eligible individual cosmetic unlocks;
• Unlock All Cosmetics;
• guarded Lock All Cosmetics;
• Clear All Presets.

Mutation authority remains separate from presentation metadata.

Unknown/future cosmetic IDs are preserved read-only rather than being silently generalized into supported mutation targets.

Locking remains guarded when known owned cosmetics are equipped, preset-referenced, or otherwise unsafe to remove.

Token editing, arbitrary equipment/color editing, and arbitrary preset creation/editing remain unsupported.

---

Upgrade metadata and artwork

Dynamically discovered upgrades can now be enriched with installed-game metadata and presentation artwork.

RepoDitor still does not rely on a hardcoded upgrade catalog for mutation identity.

Persistent derived presentation cache

Upgrade artwork decoded from installed game assets can now be persisted under RepoDitor's application data and reused across application restarts.

The cache is presentation-only.

Entries are tied to source identity/watch information and are reused only while their underlying installed-game sources remain valid.

Missing, stale, malformed, unsupported, or unreadable cache entries fail soft:

valid cache
→ reuse artwork

invalid/missing cache
→ authoritative source preparation
→ regenerate when possible

Cache corruption or persistence failure does not grant mutation authority and does not make save state authoritative.

Unreferenced derived presentation PNGs are pruned, and a read-only presentation-cache audit script is included for maintenance verification.

---

Game-generated icons and local assets

RepoDitor distinguishes between different kinds of visual data:

• R.E.P.O.-generated item/cosmetic icons remain owned by the game and are read from validated local game cache locations.
• RepoDitor-derived upgrade artwork is decoded from the installed game and stored in RepoDitor's own validated presentation cache.
• Save data has a separate authority lifecycle and is not treated as presentation cache data.

RepoDitor does not bundle or redistribute R.E.P.O. game artwork as part of the application.

Missing or unsupported artwork fails soft to RepoDitor's normal icon fallback.

---

Save Safety and Correctness

This release adds more safety checks while preserving the existing staged write architecture.

Game-running protection

R.E.P.O. can keep save state in memory and write it later, so editing while the game is running risks working against stale data or having changes overwritten.

RepoDitor therefore distinguishes:

RUNNING
NOT_RUNNING
UNKNOWN

Safety-sensitive mutation treats an unknown process state as fail-closed.

In addition to the earlier game-state check, RepoDitor now rechecks the game immediately before persistence. This closes the timing window where R.E.P.O. could start after an earlier validation but before the final write.

Fail closed on unknown scalar representations

Editable existing scalar values are no longer silently overwritten when their stored representation is unknown.

For supported Run/Player/Upgrade mutation paths, an already-present editable scalar must use the proven integer representation; unsupported existing representations are rejected.

Python's bool values are explicitly not accepted as integers for these mutation checks.

Read paths can remain appropriately fail-soft, while mutation requires stronger evidence.

Safe write pipeline

The current write design retains the important protection layers:

1. User edits remain in memory until an explicit save action.
2. Python requires a confirmed-safe game process state.
3. The current source is loaded and validated.
4. Its fingerprint is checked against the source that was opened.
5. Requested typed mutations are validated.
6. The game process is checked again before persistence.
7. The repository rereads the source and requires the expected bytes.
8. A timestamped exact-byte backup is created beside the source.
9. Encrypted output is written to staging.
10. The staged file is reopened, decrypted, validated, and compared with the intended result.
11. The source is checked again before replacement.
12. Verified staged output atomically replaces the source.
13. The backend returns canonical post-write state.

These safeguards reduce risk; they are not a guarantee against every future game-format change, operating-system failure, or form of data loss.

Back up saves you care about before using any save editor.

---

Save Freshness vs Presentation Caching

RepoDitor deliberately treats authoritative save state differently from derived presentation data.

Data	Behavior
Save state	Explicit opens ask Python to read/decrypt/validate the current .es3. Raw decrypted save JSON is not persisted.
Same-session editor-entry state	May be reused only after another fresh open confirms the same fingerprint; successful writes invalidate it.
R.E.P.O. item/cosmetic icons	Read from validated game-local cache locations and exposed through controlled presentation paths.
Derived upgrade artwork	Persisted by RepoDitor, source-validated, and regenerated/fallbacked when invalid.
Recharge evidence	Session-scoped only; must be independently revalidated by Python before reuse.
Cosmetic presentation metadata	Derived/local presentation information; never ownership or mutation authority by itself.

This separation lets RepoDitor avoid unnecessary repeated work without turning stale cached data into save authority.

---

UI and Desktop Experience

Themed Select controls

Several browser-native dropdowns were replaced with a reusable RepoDitor-themed Select component.

It includes keyboard and accessibility behavior for:

• Enter / Space;
• Arrow Up / Arrow Down;
• Home / End;
• Escape;
• normal Tab progression;
• focus restoration;
• disabled state;
• listbox/combobox semantics;
• selected-option indication.

No additional component framework was introduced.

Player health presentation

The selected-player editor now includes a compact accessible health visualization.

It reflects:

• saved health;
• valid pending health edits;
• Heal to Full;
• Revert behavior;
• the backend-calculated maximum health.

Invalid temporary input does not produce a broken progress state.

Editor iconography

RepoDitor now uses clearer semantic icons across editor navigation and field presentation while continuing to use the existing Phosphor icon family.

Stable pending-change tabs

Pending-change indicators no longer change tab width when they appear or disappear.

Players, Upgrades, Run, and Items retain their existing unsaved-change semantics while the visual indicator now occupies a stable slot.

Loading and preparation states

Save opening and game-artwork preparation are now presented as separate concepts.

Typical states include:

Opening save
Reading and validating save data…

and, only when actual presentation preparation is required:

Preparing game artwork
Decoding <asset> upgrade artwork…

Real asset completed/total counts are used only when real determinate progress exists.

---

Navigation and Editor Entry

Returning to Change Save now preserves the last successful discovery snapshot while environment discovery refreshes in the background.

This avoids unnecessarily dropping back to a cold-launch skeleton when useful discovery data is already available.

For save entry:

• required presentation readiness is resolved before Workspace becomes visible;
• genuinely missing presentation assets are prepared before entry;
• source-valid artwork can be reused;
• save-specific editor data can be prepared before Workspace presentation;
• same-save session data may be reused only after a fresh fingerprint-confirming open;
• successful writes invalidate the corresponding save-entry snapshot.

---

Security and Local Data Model

RepoDitor remains an open-source desktop application whose Electron application, Python backend, packaging configuration, tests, and CI/release workflows can be inspected in this repository.

Renderer boundary

The renderer continues to operate with:

contextIsolation: true
nodeIntegration: false
sandboxed renderer/preload boundary

The preload API exposes narrow, typed RepoDitor capabilities rather than raw ipcRenderer.

The renderer is not given:

• arbitrary filesystem access;
• arbitrary shell/process execution;
• arbitrary Python execution;
• generic IPC invocation;
• raw decrypted save JSON.

Python remains authoritative for save-format and mutation semantics.

Local save processing

Save parsing, validation, encryption, and editing are performed locally by the bundled Python backend.

Raw save files and decrypted save contents are not sent to a remote save-processing service.

RepoDitor necessarily accesses known game/application locations for supported functionality, including save discovery, backups, installed-game metadata, validated game-generated icons, and RepoDitor-owned settings/presentation caches.

Optional network-backed features

Current optional network behavior is narrowly scoped.

Examples include:

• Steam public-profile/avatar enrichment for plausible save-derived Steam IDs;
• GitHub project metadata for the RepoDitor repository.

These requests do not receive raw save files or raw decrypted save data.

The current application does not include application analytics, advertising SDKs, usage telemetry, crash-report uploads, or remote application logging.

---

Testing and Reliability

The automated suite has expanded substantially since v0.1.1.

Coverage now includes dedicated behavior around:

• encrypted save loading/writing;
• stale-source rejection;
• exact-byte backups;
• staged verification;
• game-running safety;
• second pre-persistence game-state checks;
• Players;
• dynamic Upgrades;
• Run editing;
• evidence-backed Items Recharge;
• Cosmetics;
• Maps;
• installed-build detection;
• local-data paths;
• Unity serialized-file parsing;
• texture decoding/preparation;
• icon-cache validation;
• persistent presentation-cache invalidation;
• Recharge evidence validation;
• Electron IPC contracts;
• preload/security boundaries;
• renderer state and loading behavior;
• theme contrast;
• import normalization;
• package contents;
• installer structure;
• packaged Electron smoke behavior.

Current release-cycle validation reported:

Python tests:                  343 passed, 1 skipped
Desktop component/contracts:  244 passed
Electron E2E:                 4 passed

alongside Ruff, mypy, TypeScript, ESLint, Prettier, import-normalization, release checks, bundle checks, package verification, and packaged smoke validation.

Tests use generated/sanitized fixtures and temporary copies rather than destructive automation against real user saves.

---

Packaging and Installer

RepoDitor remains a Windows x64 Electron desktop application with a bundled Python backend.

The current distribution uses:

Electron
+ React
+ bundled PyInstaller onedir Python sidecar
+ electron-builder
+ assisted NSIS installer

The installer remains current-user-first and allows choosing the installation directory.

Normal users do not need to install Python, Node.js, npm, or uv.

RepoDitor does not install an automatic updater or background service.

---

Open Source and Contributor Experience

This release includes a repository-wide source documentation pass intended to make future contribution much easier.

Production source now documents architectural ownership and important lifecycle/trust boundaries across:

• Python packages and modules;
• meaningful production __init__.py files;
• save/storage services;
• game/install discovery;
• Items and Recharge evidence;
• Cosmetics metadata and mutation policy;
• Unity parsing and texture infrastructure;
• Electron main and IPC modules;
• preload security boundaries;
• Python process client;
• persistent presentation cache;
• React feature orchestration;
• hooks and state lifetime;
• packaging/release/validation scripts.

The goal is that a future contributor can enter a subsystem and understand what it owns—and what belongs in a neighboring layer—without first reverse-engineering the whole repository.

Technical documentation has also been reorganized into clearer architecture and research sections.

---

Documentation and Transparency

The public README and supporting documentation now explain more of RepoDitor's current behavior, including:

• architecture and dependency direction;
• save safety;
• local-data behavior;
• optional network access;
• presentation caching;
• save freshness;
• packaged Python architecture;
• build/release verification;
• current limitations;
• screenshots of the current application;
• evidence-backed editing boundaries.

The project intentionally avoids claims such as "100% safe", "virus-free", or "future-proof".

Trust is instead communicated through inspectable source, documented boundaries, public build workflows, checksums, tests, and explicit limitations.

---

Current Limitations

RepoDitor remains intentionally conservative where game semantics have not been established.

Current notable limitations include:

• Windows x64 is the supported distribution target.
• Game updates may change save structures, Unity metadata layouts, or presentation assets.
• Maps remain discovery-only; RepoDitor does not inject code or force a map selection.
• Items supports evidence-backed Refill to Full, not arbitrary numeric charge/item mutation.
• Cosmetics supports only established operations; unknown/future IDs are preserved rather than automatically becoming editable.
• Steam avatar enrichment may fail softly for private, invalid, malformed, unreachable, or unsupported profiles.
• RepoDitor has no automatic updater.
• This release is unsigned unless the release page explicitly shows a valid code-signing publisher.

---

Upgrading from v0.1.1

v0.2.0 can be installed as the next RepoDitor release.

Before upgrading:

1. Close R.E.P.O.
2. Back up saves you care about.
3. Download the new installer from the official RepoDitor GitHub Releases page.
4. Verify the accompanying SHA-256 checksum.
5. Install and launch RepoDitor normally.

RepoDitor's own presentation/settings caches are separate from R.E.P.O. save files and are not mutation authority.

---

Download Verification

Download the installer and matching .sha256 file from this release.

Example:

Get-FileHash .\RepoDitor-Setup-0.2.0-x64.exe -Algorithm SHA256
Get-Content .\RepoDitor-Setup-0.2.0-x64.exe.sha256

The hexadecimal hashes should match, ignoring letter case.

A matching SHA-256 verifies that the downloaded installer matches the artifact published with this release. It does not by itself prove publisher identity or make a general claim about software safety.

---

For Developers

Clone and run from source:

git clone https://github.com/Yoruxyv/RepoDitor.git
Set-Location RepoDitor

uv sync --locked

Set-Location desktop
npm ci
npm run dev

Build a local unsigned installer:

Set-Location 'E:\GitHub\RepoDitor\desktop'
npm run package

See the repository's CONTRIBUTING.md, architecture documentation, security policy, and release checklist for the current development and release process.

---

Thank you

Thanks for trying RepoDitor and for reporting issues with enough context to reproduce them.

Focused bug reports, compatibility evidence, documentation improvements, and pull requests are welcome.

RepoDitor is an unofficial community project and is not affiliated with semiwork.