Skip to content

Contributing

Lucas YourLastName edited this page Sep 28, 2026 · 8 revisions

Contributing

Contributions should make .SYSTEMX clearer, more reliable, or easier to adopt while preserving its stack-neutral scope.

Useful contributions

  • Corrections to instructions, examples, links, or error explanations.
  • Focused fixes supported by a reproducible failure and relevant verification.
  • Improvements to task consistency, context loading, or project portability.
  • Simpler standards and templates that solve a demonstrated project need.

Discuss changes that introduce a new runtime, hosted service, mandatory provider, or major coordination model before implementing them. Keep application-specific features and individual project records out of the reusable base.

Development workflow

  1. Inspect the current standard, relevant code, and existing tests.
  2. Use a branch or fork for the scoped change.
  3. Keep reusable project records blank. Exercise task and agent workflows in temporary copies rather than adding sample work to the distributed ledger.
  4. Update affected documentation alongside behavior.
  5. Run the relevant verification and explain the result in the pull request.
bash .SYSTEMX/SYSTEMX.sh validate
bash .SYSTEMX/SYSTEMX.sh validate --template
python3 -B -m unittest discover -s .SYSTEMX/tests -v
git diff --check

For documentation changes, also check the actual links, command examples, and rendered GitHub page. Do not add a test merely to repeat static prose. Review FORMAT.md when changing canonical fields or lifecycle rules. Update blank seed hashes only for deliberately reviewed prompt changes; never rebaseline populated project records. Validate the extracted, tracked-file export before publication so ignored runtime artifacts are not shipped.

Pull requests and bug reports

Describe the concrete problem, resulting behavior, and evidence that the change works. Include reproduction steps, the affected template version, operating system/runtime where relevant, and sanitized output. Record limitations instead of implying broader coverage than the checks provide.

Use the issue tracker for ordinary bugs and proposals. Keep secrets, credentials, customer data, and private security details out of public reports.

Maintain documentation sources

The root README introduces the distribution. The .SYSTEMX documents remain self-contained for people copying the operating folder into another project. The wiki provides longer guides and links back to canonical files.

GitHub stores wiki content in its own Git repository. Maintainers can edit it locally and push changes to its default branch, following GitHub's wiki editing guide. Update related guide pages and navigation together.

License and provenance

Contributions are made to the independent WayneTechLab/dotSYSTEMX repository. The original upstream template remains separately maintained. Preserve the MIT license notice and keep SOURCE.json accurate about the original source and extraction scope.

DOT SYSTEMX · User manual

1. Start here

2. Work and continuity

3. Setup and maintenance

4. Advanced reference

5. Project information

Repository · Use this template · MIT license

Clone this wiki locally