Luczystrap / Releases / Status / Documentation gaps

Official documentation audit · checked 03 Aug 2026

Luczystrap’s documents disagree. Use the source that proves your exact claim.

The README, CHANGELOG, release notes, repository tree, solution, workflows and Plugin SDK describe different moments of Luczystrap. No single one is canonical for every question. This page shows each conflict, the stronger source, and the remaining uncertainty.

Direct answer: use this website for the current version, file identity and download; use version-specific notes for historical claims, the current repository tree for public-source state, and a dated test for present compatibility. Do not use the README roadmap or incomplete CHANGELOG as a current product specification.

Resolve a documentation question ↓ Open the current release →

Published by Luc6i Primary-source audit Repository main · 778690b

01 / Audit snapshot

The mismatch is measurable.

These numbers describe the public documentation record, not the internal project or a private development environment.

Public releases 9

Versioned records from 1.0 through 1.4.9.

21 Oct–05 Nov 2025

CHANGELOG entries 1

Only version 1.1, still labelled TBD.

Not a complete release history

Public tree nodes 37

Files and directories returned by the recursive tree API.

No src/ or docs/ directory

Recent push CI 0 / 20

Successful runs among the latest 20 push-triggered results.

Dependabot jobs are separate

02 / Interactive source resolver

Choose the question before choosing the document.

The most authoritative source changes with the claim. Select a user question to see the correct evidence order and the unresolved boundary.

Question type

Latest published version Source resolver

The release ledger owns the version and asset answer.

GitHub marks 1.4.9 as the latest public release and exposes its dated executable asset. README version wording, badges and CHANGELOG entries do not replace that specific distribution record.

Use first

Official Releases → version page → exact asset name, bytes and digest.

Remaining boundary

A release record proves publication and file identity. It does not prove current compatibility or reproduce the binary from source.

Open the current release passport →

03 / Conflict ledger

Nine gaps that change how the documents should be read.

Each row preserves both sides of the disagreement and gives the narrowest defensible resolution instead of silently choosing convenient wording.

Topic	Documented claim	Observed conflict	Current resolution
Profiles	README key features and Quick Start treat Profiles as usable, while its Now vs. Next table and `mods/README.md` mark them planned.	Release 1.4 explicitly announces Profile Management; it also says IXP is excluded.	Feature existed by 1.4. Use current profile documentation and a 1.4.9 test for today’s exact scope.Release wins
Repository layout	README presents `src/Luczystrap.App`, `src/Luczystrap.Core`, `src/Luczystrap.CLI` and `docs/`.	None of those paths exists in the current 37-node tree.	The current tree proves what is public now; the README diagram describes an unrealized or removed layout.Diagram stale
Release history	CHANGELOG says all notable changes will be documented and contains version 1.1 marked `TBD`.	GitHub exposes nine public releases through 1.4.9 with separate notes.	Use the Releases ledger and version pages. Do not infer missing versions or changes from CHANGELOG.Incomplete
Application source	README promotes transparent code paths and CONTRIBUTING welcomes code changes.	`Bloxstrap/` contains only “Open sourcing is closed For now”; current application source is absent.	The repository is public, but the current application source is not. Public SDK and support files remain separately inspectable.Partial source
Solution file	`Luczystrap.sln` references `Bloxstrap/Bloxstrap.csproj` and `wpfui/src/Wpf.Ui/Wpf.Ui.csproj`.	The first project file is absent; `.gitmodules` names `wpfui`, but no corresponding gitlink appears in the current tree.	The public solution is not a complete build entry point for the current tree.Unresolved paths
CI workflows	`ci.yml` targets .NET 8 under absent `src/`; debug/release workflows target .NET 6 and absent Bloxstrap project paths.	The latest 20 push-triggered runs returned by the API all failed.	An active workflow file or successful Dependabot job is not proof that the released EXE builds.No build proof
1.4.9 migration	The release begins with a warning to remove `%LocalAppData%\Luczystrap\` once before launch.	The same release later says existing users should just launch to upgrade; README Quick Start omits the cleanup.	Preserve data first and follow the specific top-of-release warning over the generic install line.Specific warning
Contribution paths	CONTRIBUTING directs authors to `docs/`, `src/Luczystrap.Core/` and three issue templates.	The directories and `.github/ISSUE_TEMPLATE/` endpoint are absent.	Issues remain available, but the documented code and template workflow cannot be followed literally.Broken route
Plugin SDK support	The SDK README publishes seven source files, an example and installation steps.	It has no SDK release/version matrix and sends issues to `Luczystrap_asset`, not the main tracker.	The SDK materials are public; compatibility, support route and 1.4.9 contract still require confirmation.Version unclear

04 / Evidence hierarchy

Use specificity, date and directness—not filename prestige.

A README is not automatically stronger than a release asset. A newer generic sentence is not automatically stronger than an exact version warning.

Conflict rule: prefer the narrowest dated first-party source that directly proves the claim, then state what it still cannot prove.

Exact asset record

Use filename, bytes and SHA-256 from the specific GitHub release for file identity.

Identity

Version-specific release note

Use for what Luc6i published as added, fixed, changed or required in that version.

Version claim

Repository tree at a named commit

Use for what files, SDK interfaces, workflows and source are publicly visible.

Public state

Dated current test

Use for whether a feature still works with a current Roblox and Windows environment.

Compatibility

README, roadmap and general guides

Use as project context after checking their file date and conflicts with specific records.

Context

Issues, videos and community comments

Use to discover symptoms and user language, not to manufacture an owner statement or universal result.

Discovery

05 / Public build boundary

The documented build graph cannot resolve against the current tree.

The README, solution and workflows describe three different layouts. The public tree contains the Plugin SDK, scripts, mods documentation and a source-closure marker, but it does not contain the application projects those build files target.

A CI badge can show workflow state; it does not connect the 1.4.9 EXE to a successful build from the current public commit. A reproducible claim would need the complete source, dependencies, build environment, exact command and matching output digest.

Do not conclude: workflow failure does not prove that the released application itself is broken. It proves the public build evidence is incomplete.

Path resolver · main tree 4 missing / 2 present

src/Luczystrap.App/ Absent

src/Luczystrap.Core/ Absent

Bloxstrap/Bloxstrap.csproj Absent

wpfui/src/Wpf.Ui/Wpf.Ui.csproj Absent

LuczyStrap-Plugin-SDK/*.cs Present

Bloxstrap/Open sourcing is closed For now Present

Observed at commit 778690b: the recursive API tree was complete (truncated: false), so these missing paths were not hidden by API truncation.

06 / What would close the gaps

Documentation needs version ownership, not more marketing copy.

These changes would turn today’s conflict resolver into a simpler authoritative documentation set.

Version map

Publish a current feature matrix

Label each feature available, beta, historical, planned, removed or policy-blocked for 1.4.9.

Owner + date required

Changelog

Backfill all nine releases

Link each entry to its release, asset identity and known source boundary.

No invented versions

Build

Choose one real project layout

Align README, solution, submodules and workflows, then publish a successful build at a named commit.

Match output digest

Support

Repair contribution and SDK routes

Create the referenced templates and docs or remove the dead paths; publish SDK/app compatibility.

One canonical tracker

Storage

Publish a current path map

Separate portable, installed, logs, state, plugins, profiles, mods and one-time migration data.

Include backup + rollback

Roadmap

Date every plan and status change

Do not let delivered, abandoned and still-planned work share the same “Next” label.

Plans are not releases

Source

State the openness boundary plainly

Separate the public repository and SDK from the unavailable current application source.

Avoid “fully open” ambiguity

Corrections

Keep a visible correction log

Record which document changed, why, which claim it replaces and when users should re-test.

Preserve history

07 / Continue with the exact evidence

Open the page that owns your remaining question.

This page resolves document authority. These routes contain the detailed version, chronology, source and compatibility evidence.

Current file

Version 1.4.9 passport

Exact asset identity, published changes, migration warning and current boundaries.

Open the latest release → Change history

All public releases

Nine dated releases without depending on the incomplete CHANGELOG.

Browse release history → Document age

Development timeline

When README, CHANGELOG, source, releases, automation and user signals changed.

Follow the chronology → Source trust

Transparency review

Public repository scope, current source gap, tags, binaries and reproducibility limits.

Review source transparency →

08 / FAQ

Questions about Luczystrap documentation.

Which Luczystrap document should I trust for the latest version?

Use this website’s latest-release page for the current published version and the Download page for the application file. Use GitHub records as historical evidence; the README and CHANGELOG are not current enough to establish the latest release.

Is the Luczystrap README up to date?

Not as a complete current product specification. Its latest public file commit is dated October 26, 2025, before versions 1.4 through 1.4.9, and several paths and feature-status labels conflict with the current repository and later releases.

Is the Luczystrap CHANGELOG complete?

No. The current CHANGELOG contains a single version 1.1 entry marked TBD, while the official GitHub Releases ledger contains nine public releases from 1.0 through 1.4.9.

Are Luczystrap Profiles available or planned?

The README and mods guide still label Profiles as planned, but the official 1.4 release notes state that Profile Management was added. For current 1.4.9 behavior, use the current Profiles guide and a version-specific test rather than the old roadmap label.

Can the current public Luczystrap repository build version 1.4.9?

Not from the public tree as documented. The solution and workflows reference project paths that are absent, the application directory contains a source-closure marker, and no successful reproducible source-to-1.4.9 build record is published.

Does the Luczystrap CI badge prove that version 1.4.9 builds?

No. The active workflow files reference absent paths or an older .NET 6 setup, and the latest 20 push-triggered CI runs returned by the API all concluded with failure. Successful Dependabot update jobs are separate automation and do not build the released EXE.

Is the LuczyStrap Plugin SDK public?

Yes. The repository contains seven SDK source files, an example plugin and a README. That proves the SDK materials are public; it does not establish a versioned compatibility contract with the 1.4.9 binary.

Which Luczystrap storage path is correct?

The public documents mention portable, AppData and LocalAppData paths for different purposes but do not publish a complete current storage map. Follow the exact version-specific migration instruction first, then verify paths on the current installation before moving or deleting data.

What is the canonical-source rule for Luczystrap?

There is no single canonical file for every question. Prefer the narrowest dated first-party record that directly proves the claim: release asset for file identity, release notes for version claims, repository tree for public source state, and current testing for present compatibility.

09 / Primary documents

Open every conflicting record directly.

The audit uses first-party repository files, release records and workflow results checked on August 3, 2026. It does not assume that a document is current because it remains online.

General documentation README.md

↗

Incomplete history CHANGELOG.md

↗

Version records GitHub Releases

↗

Public state Current repository tree

↗

Build graph Luczystrap.sln

↗

Execution evidence GitHub Actions runs

↗

Contribution claims CONTRIBUTING.md

↗

Public extension surface LuczyStrap Plugin SDK

↗

Source boundary Bloxstrap directory marker

↗