Files
StepForge/docs/CONTRIBUTING.md
TylerandClaude Fable 5 07e6191cc1
Template tests / tests (pull_request) Failing after 32s
Reconcile the license to CC BY-NC 4.0 (owner decision)
The repo contradicted itself — package.json/CONTRIBUTING said MPL-2.0 (permits
commercial use) while README/docs/LICENSE said Creative Commons NonCommercial
(forbids it), with no root LICENSE. The owner chose Creative Commons
Attribution-NonCommercial 4.0 International; this makes every surface agree.

- Add a root LICENSE with the full official CC BY-NC 4.0 legal text plus a
  StepForge copyright header and SPDX identifier. Packages already ship it as
  the copyright file (verified in the built .deb).
- package.json license -> CC-BY-NC-4.0; RPM spec License -> CC-BY-NC-4.0.
- docs/LICENSE becomes a short pointer to the root LICENSE (no more competing
  paraphrase); README and CONTRIBUTING state CC BY-NC 4.0 (contributions
  licensed under the same license + DCO sign-off for provenance).
- app:info now reports the license so the About view can't contradict.
- New tests/unit/license.test.js guards consistency: root LICENSE present with
  the full legal text, package.json is CC-BY-NC-4.0, no shipping surface
  mentions MPL, and the story matches across README/CONTRIBUTING/docs/spec.
  Updated the RPM-spec packaging test accordingly.

Note: the historical planning archives under ai_prompts/ still mention the old
MPL target; they are point-in-time design notes, not the license, so they are
left as-is.

Verified: 289 unit tests pass; the built .deb ships the CC BY-NC 4.0 text as
its copyright file.

Co-Authored-By: Claude Fable 5 <[email protected]>
2026-07-04 14:17:42 -05:00

3.2 KiB

Contributing

Thanks for improving StepForge.

Before You Start

  • Open or link the issue that describes the work.
  • Keep the change small and focused.
  • If the work does not have an issue yet, create one first so the PR can reference it.

Clean-Room Rules

StepForge is an independent reimplementation of publicly documented guide-capture workflow patterns. To keep it legally clean:

  • Do not use the names, logos, icons, screenshots, or UI strings of commercial documentation products anywhere in code, assets, or docs.
  • Do not copy wording from other products' documentation into the UI.
  • Do not decompile, disassemble, or otherwise inspect proprietary binaries to derive behavior.
  • Implement behavior from public descriptions and your own design only.
  • Keep file formats (.sfgz, .sfglt, guide/step JSON) documented and versioned in docs/ and ARCHITECTURE.md.

StepForge is licensed under Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) — see the root LICENSE. By contributing you agree that your contributions are licensed under that same license, and you add a Developer Certificate of Origin sign-off to each commit (git commit -s) to certify you have the right to submit them.

Offline Rules

  • No network code paths in the application. No telemetry, update checks, license checks, remote fonts, or remote APIs — ever.
  • No new runtime dependencies without prior maintainer agreement; prefer internal implementations using Node built-ins. This is due to all the security issues that have arrose lately with NPM dependencies.

Branching

  • Use a branch name that includes the issue number, such as issue-123-update-readme.
  • Keep unrelated cleanup in a separate branch, only have the fix in the branch.

Pull Requests

  • Every pull request must reference an issue number in the body with Closes #123, Fixes #123, or Relates to #123.
  • Summarize the change clearly and call out anything a reviewer should verify manually.
  • Update docs when behavior changes.
  • Every exporter or storage change requires tests; output changes require updated snapshot fixtures under tests/fixtures/.

Tests

Run the local checks before opening or updating a PR:

bash tests/run_test.sh

Put new shell checks in tests/checks/ so the shared runner picks them up automatically. The shell checks invoke the node --test workflow suites in tests/unit/.

Write tests that exercise real workflows and verify actual output — create a guide, export it, parse the bytes that came out. DO NOT WRITE A TEST THAT GREPS FOR CODE.

The Gitea workflow in .gitea/workflows/tests.yaml and .github/workflows/ci.yaml runs the same command automatically on pushes and pull requests.

Please add lots of tests to each of your PR's and be descriptive with the tests so that the issue doesn't happen again or the feature doesn't get overwritten.

Review Checklist

  • The PR is linked to the correct issue.
  • The test suite passes locally.
  • Any relevant docs or comments are updated.
  • The change stays within the intended scope.
  • The PR body explains any manual verification that is still needed.
  • No network calls, no new dependencies, no trademarked assets.