App × SDK × plugin · audited 03 Aug 2026

The SDK is public. Its version contract is not.

Q: Can I copy all seven SDK files into a plugin project?

Not reliably as currently published. ILuczyStrapPlugin.cs repeats types also declared in separate files, while PluginLogger.cs and PluginThemeManager.cs reference the internal App class. The seven-file instruction therefore needs correction before it can be treated as a reproducible build recipe.

Q: What files make up a Luczystrap plugin?

The official example documents a DLL and plugin.json inside a folder whose name matches the plugin ID. The README gives the path %LocalAppData%\Luczystrap\Plugins\ \ and says the DLL should also use that ID.

Q: Does isTrusted make a plugin safe or compatible?

No. IsTrusted is a metadata field described as team verification. The public SDK does not document verification criteria, a signature scheme, permissions, sandboxing or an app compatibility guarantee.

Q: How do I test a Luczystrap plugin after an update?

Record the exact app and plugin versions, prove Luczystrap and Roblox work without plugins, add one reviewed plugin, verify load and lifecycle logs, then disable or remove it and confirm a clean restart.

Q: Does a successful .NET 8 build prove plugin compatibility?

No. A build proves only that the selected source and references compile. Loader discovery, interface identity, dependencies, manifest handling and lifecycle callbacks still require a runtime test in the exact Luczystrap version.

Q: Are old Luczystrap plugins compatible with 1.4.9?

No blanket answer is published. Releases after 1.4 do not name a stable SDK level, and the current loader source is unavailable. Treat an old plugin as unverified and test it without other plugins.

Luczystrap introduced community plugins in 1.4. The repository exposes a .NET 8 interface set and an example, but it does not publish a tested mapping between app versions, SDK revisions and plugin builds.

Current verdict: plugins are not proven incompatible with 1.4.9; they are unverified per package. A matching manifest or successful build is only one checkpoint—the exact loader and lifecycle still need a clean runtime test.

Check a plugin ↓Open official SDK ↗

Written by Luc6iCurrent app: 1.4.9Evidence checked: 03 Aug 2026

01 / Published surface

What the repository actually gives us.

These counts describe the public SDK folder, not the private loader inside the current executable.

SDK source7

Top-level C# files listed in the official folder.

Some declarations overlap

Reference sample1

Example class plus a sample plugin.json.

No sample project file

SDK history1

Public SDK commit: 778690b, dated October 28, 2025.

No numbered SDK release

Version matrices0

No published table maps app, SDK and plugin versions.

Runtime result remains unknown

02 / Compatibility resolver

Start with the artifact you have.

Select the closest case. The result distinguishes what can be inferred from public evidence from what still needs proof.

Plugin situation

Official example sourceEvidence-led result

Useful as an API example—not a reproducible package.

The class shows metadata, logging, persistent settings and four lifecycle callbacks. The repository does not include a .csproj, built DLL, test result or app-version declaration for it.

What is established

The intended interface shape and a sample manifest are public.

Required next proof

Create a corrected project, record the SDK source commit, build it, then test discovery and all callbacks in the exact app version.

Inspect the official example →

03 / App–SDK history

Release notes confirm a feature, not a stable ABI.

“No published statement” means unknown. It does not mean a plugin definitely fails.

App release	Official plugin evidence	SDK compatibility statement	Decision today
1.4 · 28 Oct 2025Introduced	Community modding and the Plugin SDK were announced and linked.	No numbered SDK level, binary contract or supported dependency range was stated.	Historical origin only. Do not install 1.4 as a compatibility fallback.
1.4.1 · 28 Oct 2025Logging fix	Release notes say plugin-system errors now log instead of silently failing.	No interface revision or plugin migration note was published.	Logs became better evidence, but they do not certify a plugin.
1.4.5 · 02 Nov 2025No SDK note	The release focuses on protocol, uninstall, shortcut and launch fixes.	No plugin compatibility declaration appears in the release record.	Unknown per plugin.
1.4.9 · 05 Nov 2025Current · test	The current public release does not name a plugin or SDK compatibility level.	Current loader source and an app-to-SDK test matrix are unavailable.	Use 1.4.9 as the app baseline; isolate and test one reviewed plugin.

04 / Public API map

What a plugin is expected to meet.

The SDK source exposes useful shapes. It does not document semantic versioning, thread rules, timeouts, cancellation, assembly loading, dependency resolution or a stable binary-compatibility promise.

Boundary: interface match ≠ loader match; successful load ≠ safe behavior; isTrusted ≠ a public security attestation.

Lifecycle

`ILuczyStrapPlugin`

OnLoadAsync returns success; unload, Roblox launch and Roblox close callbacks return tasks. Callback order and failure handling are not fully specified.

Context

`PluginContext`

Provides data directory, logger, settings, mod and theme managers, plus Luczystrap and Roblox version strings.

Identity

`PluginMetadata` + `plugin.json`

ID, name, author, version, type, dependencies, URLs, dates, counts, tags, restart and trusted fields. The ID must match the folder and DLL name according to source comments and setup guidance.

Storage

`IPluginSettingsManager`

Generic Get, Set and Save methods. Format, concurrency, migration and corruption behavior are not documented.

Resources

`IPluginModManager`

Install or remove a target-path override and obtain the mods directory. Roblox resource layout remains a separate compatibility layer.

Themes

`IPluginThemeManager`

The interface exposes apply, register and current-theme methods. In the published implementation file, apply and register are marked TODO and only log calls.

05 / Reproducibility blockers

Why “copy seven files” is not enough.

These are source-level findings in the official SDK folder, not assumptions about a plugin that has already been corrected by its author.

DUP

Types are declared twice.

ILuczyStrapPlugin.cs contains metadata, context and manager interfaces also present in separate files. Copying every file into one namespace creates duplicate definitions.

Published quick start needs a canonical file set

APP

Two files are loader-side implementations.

PluginLogger.cs and PluginThemeManager.cs use the internal App object. They cannot act as self-contained external SDK contracts without the application assembly.

Contract files and host files are mixed

PKG

No versioned build artifact exists.

The folder has no SDK .csproj, NuGet package, package version, compatibility range or compiled reference distributed with a release.

Pin source commit 778690b when testing

06 / Controlled runtime test

Prove one plugin without risking the baseline.

Use a disposable plugin folder and keep the original package outside Luczystrap. Record exact versions and hashes so the result can be repeated.

Stop immediately if the plugin is binary-only with no trustworthy origin, asks for Roblox cookies or unrelated secrets, makes unexplained network requests, prevents clean startup, or cannot be removed.

Freeze the identitiesRecord Luczystrap version, EXE hash, plugin version/hash, source commit, manifest and dependency files.

Record

Prove the stock baselineMove all plugins out, launch Luczystrap twice, start and close Roblox, then preserve the clean log.

Baseline

Review one packageCheck source, ID/folder/DLL match, target framework, dependencies, settings, file writes and network behavior.

Inspect

Load only that pluginPlace its DLL and manifest in the documented folder, enable it, restart and read the newest Luczystrap log.

Load

Exercise the lifecycleConfirm load, Roblox launch, Roblox close and unload paths; test only the feature the plugin claims.

Observe

Remove and re-prove clean stateDisable or move the plugin out, restart twice and verify the original baseline returns.

Rollback

07 / Continue by intent

Keep compatibility separate from history and trust.

This page owns the app–SDK–plugin chain. Use the related page that owns the next decision.

All layers

Compatibility matrix

Windows, Roblox, FastFlags, mods and plugins in one system view.

Return to matrix →Feature origin

Version 1.4 history

Why plugins arrived alongside profiles, cursor transfer and IXP.

Read the release record →Evidence limits

Documentation gaps

Which public files are current, historical, duplicated or missing.

Review source hierarchy →Runtime evidence

Find Luczystrap logs

Locate the newest log before and after a plugin test.

Open log guide →

08 / FAQ

Luczystrap plugin compatibility questions.

Does Luczystrap 1.4.9 support plugins?

The public record shows a plugin system introduced in 1.4 and plugin error logging improved in 1.4.1. No app-to-SDK matrix or current 1.4.9 loader test is published, so each plugin remains unverified until tested.

Which Luczystrap SDK version should a plugin target?

The repository provides one unversioned SDK source snapshot from commit 778690b and instructs developers to target .NET 8. It does not publish a numbered SDK package or map SDK versions to app releases.

Can I copy all seven SDK files into a plugin project?

Not reliably as currently published. ILuczyStrapPlugin.cs repeats types declared in separate files, while PluginLogger.cs and PluginThemeManager.cs reference the internal App class. The seven-file recipe needs correction.

What files make up a Luczystrap plugin?

The official example documents a DLL and plugin.json inside %LocalAppData%\Luczystrap\Plugins\<plugin-id>\. Source comments and the setup guide say the folder and DLL names must match the plugin ID.

Does isTrusted make a plugin safe or compatible?

No. isTrusted is metadata described as team verification. The public SDK does not document its criteria, a signature scheme, permissions, sandboxing or an app compatibility guarantee.

How do I test a Luczystrap plugin after an update?

Record exact app and plugin versions, prove Luczystrap and Roblox work without plugins, add one reviewed plugin, verify load and lifecycle logs, then remove it and confirm a clean restart.

Does a successful .NET 8 build prove plugin compatibility?

No. It proves only that the selected source and references compile. Loader discovery, interface identity, dependencies, manifest handling and lifecycle callbacks still require a runtime test in the exact app version.

Are old Luczystrap plugins compatible with 1.4.9?

No blanket answer is published. Later releases do not name a stable SDK level, and current loader source is unavailable. Treat an old plugin as unverified and test it without other plugins.

09 / Primary evidence

Official files behind every status.

Method: I compared the current SDK tree and source, example package, SDK commit history and official releases. A release announcement establishes intent; source establishes exposed shapes; only a dated runtime test can establish a plugin result.

01Official Plugin SDK folderSeven C# files, README and example package.↗02SDK setup guide.NET 8, seven-file copy instruction, folder and Plugin Manager route.↗03Main interface sourceLifecycle plus repeated metadata, context and manager declarations.↗04Plugin metadata sourceIdentity, versions, dependencies, restart and trusted fields.↗05Published theme managerInternal App dependency and TODO apply/register methods.↗06Official example pluginLifecycle implementation and sample manifest; no project or DLL.↗07Luczystrap 1.4 releaseOriginal Plugin SDK and community modding announcement.↗08Luczystrap 1.4.1 releasePlugin-system errors log instead of silently failing.↗09Current 1.4.9 releaseNo published SDK compatibility level in the current notes.↗10Current application-source markerThe loader implementation cannot be audited from the current public app tree.↗