Contributor guidelines

rules: few, but firm principle: boring and verifiable

01Read first

Before touching anything: the legal note (contributions are made under the project's all-rights-reserved terms), this page, and architecture. The project is small and intends to stay small; scope creep is rejected more often than it's merged.

02Reporting issues

One issue per problem. No "also, by the way…" appendices.
Include the Lurelock version, the client version, and the relevant log excerpt from %APPDATA%\lurelock\logs.
Label concrete, reproducible steps. "It broke" without steps gets closed as unactionable.

03Flag submissions

Adding a flag to the decision table means taking responsibility for its rating. Supported flags require evidence: client version, observed effect, and repeatability. A flag without evidence goes in as community, never as supported. Ratings can be demoted by anyone with a conflicting result and a log.

04Pull requests

Branch from the main working branch, keep the diff small and the commit per change.
No empty messages, no "style", no unrelated renames.
Run the build pipeline locally: npm run build:app plus a browser pass in demo mode.
If a change touches the manifest format, it must migrate: old manifests read fine after upgrading.

05Review standards

Reviewers answer one question per PR: "can I verify this actually does what it says?" If the answer needs more than a glance at a diff plus a quick run, the PR gets sent back for a clearer description or a test. Merges happen on the working branch, not silently on main.