Transparency ledger · Checked August 6, 2026

Public repository. Incomplete release proof.

Luczystrap publishes a GitHub repository, MIT license, Plugin SDK, release history and a hash for 1.4.9. It does not publish the current application source or a reproducible source-to-EXE chain.

Exact wording: Luczystrap is partially open source. Public historical code and SDK files can be reviewed; the current 1.4.9 application binary cannot be independently rebuilt from the public main tree.

Open the evidence ledger  ↓ Inspect every source tag  →
Independent evidence snapshot Dated, not permanent
Partial transparency

Repository visibility and binary reproducibility are separate.

A public repo answers “what files are published?” Reproducibility answers “can these exact inputs recreate this exact release?”

REP
Repository + MIT license Public main tree and historical refs
Published
SRC
Current application source Bloxstrap folder contains one empty closure marker
Unavailable
TAG
1.4-family revision identity Seven tags resolve to commit 778690b
Collapsed
EXE
Release file identity 1.4.9 asset includes a GitHub SHA-256 digest
Published
Scope · Public evidence only Verdict · Not reproducible

01 / One-sentence answer

Three claims that must remain separate.

“Open source” becomes misleading when repository visibility, license permissions and current binary provenance are collapsed into one badge.

Confirmed

The repository is public and MIT-licensed.

Anyone can inspect its current 37-entry tree, history, tags, SDK, documentation, workflows and declared license terms.

Repository API + LICENSE · checked 2026-08-06
Partial

Reviewable code exists, but not the current app.

Historical tags expose earlier application snapshots and main contains the Plugin SDK. The current app directory contains no application source.

Bloxstrap/Open sourcing is closed For now · zero-byte marker
Not established

Luczystrap 1.4.9 is not publicly reproducible.

No published chain connects complete current source, a unique version revision, exact build inputs and an independently matching EXE.

File hash is published; provenance chain is incomplete

02 / Interactive evidence ledger

Ask one transparency question at a time.

Select a record to see what the public evidence proves, what it cannot prove and the wording this site will use until the record changes.

Choose an evidence record

Confirmed public Snapshot · 2026-08-06

The GitHub repository is public and unarchived.

GitHub reports public visibility, main as the default branch, MIT as the detected license and archived: false. Public access permits inspection; it does not make every product version source-complete.

Verifiable record github.com/Luc6i/Luczystrap · visibility public · branch main · archived false · license MIT
Proves The current repository record is inspectable

Files, refs, issues, releases and declared repository metadata are publicly accessible.

Does not prove Current binary source completeness

A public repository can omit the source or build inputs used for a distributed executable.

Site wording: “public repository,” not “fully open-source current application.”

03 / Public inventory

What each repository area can actually establish.

A file can be useful evidence without answering every question. This table prevents documentation, license text or an automation file from being treated as current application source.

Record Current public state What it proves What it cannot prove Status
Default branch main at 778690b Current public revision and 37-entry tree That this tree produced release 1.4.9 Public
Application directory One zero-byte marker named Open sourcing is closed For now The current tree intentionally does not expose app files there Implementation or behavior of the distributed app Missing
Plugin SDK Interfaces, managers, README and example plugin Published developer contract and intended plugin surfaces Current closed loader implementation or enforcement Public
Historical tags Earlier refs retain historical source states Versioned evidence for older snapshots Current 1.4.9 implementation when tags collapse Historical
MIT LICENSE Copyright 2025 Luc6i and contributors Declared permissions, conditions and warranty disclaimer Safety, audit result or source-to-binary identity Published
Release 1.4.9 EXE, date, size, notes and GitHub SHA-256 Canonical asset record and exact byte identity Complete build inputs or matching public source Artifact
CI (Release) Active workflow file targeting missing app project and .NET 6 An intended historical automation recipe A runnable current-main build or link to the 1.4.9 asset Stale path
SECURITY.md Private Discord DM route and claimed 48-hour acknowledgement Project-authored reporting instructions Dedicated email, private GitHub form or measured response performance Partial

License boundary: this page describes evidence, not legal advice. The MIT file states permissions and an “as is” warranty disclaimer; it does not substitute for the missing current source or a security assessment.

04 / Reproducibility chain

The release can be identified—but not recreated.

A trustworthy release chain needs each link. Publishing the final digest is valuable, but it cannot repair missing source, collapsed version refs or an unconnected build process.

01
Complete current source

The application project used for 1.4.9 must be available with dependencies and generated inputs.

main/Bloxstrap/ → only “Open sourcing is closed For now”
Missing
02
Unique version revision

A version tag should resolve to the exact source state represented by that release.

1.4Beta · 1.4 · 1.4.1 · 1.4.5 · 1.4.6Beta · 1.4.9 · 1.4.9.9 → 778690b
Collapsed
03
Runnable build recipe

Toolchain versions, dependency locks and build commands must run against the published revision.

ci-release.yml → .NET 6 + .\Bloxstrap\Bloxstrap.csproj (project absent from main)
Incomplete
04
Attested release output

The published asset should be connected to the revision and workflow that created it.

Release asset exists; no public source-build attestation links it to 778690b
Unlinked
05
Exact asset identity

A local file can be compared byte-for-byte with the canonical GitHub release asset.

SHA-256 d71c31057677bc392f680c6303dcfda9fa8f366240284dac6d5a14f7cc352424
Published

Result: a matching hash proves that the local file equals the canonical 1.4.9 asset. It does not show which source produced those bytes or whether the code is safe.

05 / Tag collapse

Seven release labels. One public source state.

These lightweight tag refs are public and useful as records. Because they resolve to one commit, they cannot distinguish the code changes claimed across the seven labels.

1.4Beta 778690b35adc… commit
1.4 778690b35adc… commit
1.4.1 778690b35adc… commit
1.4.5 778690b35adc… commit
1.4.6Beta 778690b35adc… commit
1.4.9 778690b35adc… commit
1.4.9.9 778690b35adc… commit

06 / Maintenance snapshot

Available does not automatically mean actively maintained.

Maintenance is a time-sensitive status, not a permanent feature. These public signals are reported with dates and without converting silence into a discontinuation claim.

Repository

Public and not archived

GitHub reports archived: false and disabled: false for the official repository.

Positive availability signal · not a support promise
Main commit

October 28, 2025

The latest public main revision is 778690b, authored as “Modding Tools.”

Current public source history boundary
Latest release

November 5, 2025

Release 1.4.9 remains the latest public release and contains one Windows executable asset.

Artifact release signal · no current roadmap
Open queue

212 issues + pull requests

GitHub’s open_issues_count combines open issues and pull requests; it is workload evidence, not a bug count.

Snapshot on 2026-08-06 · value will change

Current label: unconfirmed. The evidence does not support a current active-maintenance guarantee, but an unarchived repository and absent official closure statement also do not prove discontinuation.

07 / Vulnerability reporting

A security policy exists, with a narrow private route.

The project-authored policy is evidence of reporting intent. Response performance and confidentiality still depend on the actual private channel and maintainer behavior.

Published SECURITY.md

Do not disclose a vulnerability publicly.

The policy directs reporters to privately message a maintainer through the project Discord and include enough information to reproduce and assess the issue.

01 / Description Explain the security issue

State affected feature, version and observed behavior without publishing exploit details.

02 / Reproduction Provide exact safe steps

Include minimum conditions and redacted evidence; never share live credentials.

03 / Impact Describe realistic harm

For example data exposure, account risk, unwanted execution or application failure.

04 / Private contact DM a maintainer

The policy names Discord and states a target acknowledgement within 48 hours.

08 / Closing the gaps

Six publishable changes would materially improve trust.

These are concrete evidence improvements—not requests for marketing badges or absolute safety claims.

01

Publish current application source

Include the exact 1.4.9 project, dependencies, generated inputs and source history.

Closes the largest audit boundary
02

Use unique immutable release refs

Give every release one commit or annotated tag that represents its exact source state.

Restores version-level traceability
03

Make the build reproducible

Pin toolchain and dependencies, document commands and compare independent output hashes.

Connects source to bytes
04

Attest release assets

Publish workflow provenance, revision identity, checksums and signing information with each asset.

Creates an auditable release chain
05

Publish a maintenance policy

Name supported versions, current maintainers, roadmap or end-of-life state and update cadence.

Replaces inference with a project statement
06

Strengthen private reporting

Add a dedicated security address or private-reporting form, supported versions and response stages.

Improves reporter access and accountability

09 / Direct answers

Luczystrap transparency FAQ.

Each answer distinguishes a public claim, a verifiable record and the stronger conclusion that the record cannot support.

10 / Primary evidence

Open every record behind the verdict.

Repository, ref and release sources are linked directly. GitHub documentation explains what release integrity and security-policy features can establish.

Official repository Public tree, metadata, history, issues and releases
↗
GitHub repository API Visibility, archive status, dates, license and open queue
↗
Current application directory Source-closure marker and absent application project
↗
Public Plugin SDK Interfaces, managers, metadata and example plugin
↗
MIT LICENSE Declared permissions, conditions and disclaimer
↗
SECURITY.md Private reporting route and acknowledgement claim
↗
Official release 1.4.9 Asset, date, size, notes and GitHub digest
↗
Main commit 778690b Shared target of seven 1.4-family tags
↗
CI (Release) workflow Published .NET 6 build and missing project reference
↗
GitHub Docs · Release integrity Immutable releases and local asset verification
↗
GitHub Docs · Security policy Purpose and expected policy information
↗
Luczystrap source and tag audit Full ref map and reproducibility evidence
→
Luczystrap documentation gaps Conflicts, unsupported claims and source hierarchy
→
Luczystrap SHA-256 guide Verify the local 1.4.9 asset without running it
→

Checked August 6, 2026. Repository state, counts, branches, workflows and maintenance signals can change after publication. This ledger treats the official repository and GitHub API as primary records, distinguishes direct evidence from inference and does not interpret a public license, workflow badge, release digest or unarchived repository as a security certification. Luczystrap is a third-party project and is not affiliated with or endorsed by Roblox Corporation.