Repository navigation
Contributing
This is a beta prerelease project. Review the canonical contribution guide, release policy, and
security and support. Alpha1 contains the integrated
branch history; main remains the public default. Released tags are retained.
Keep feature branches temporary and remove them once their work is included in
both standing branches and no open pull request or worktree needs them.
Contributions should make .SYSTEMX clearer, more reliable, or easier to adopt
while preserving its stack-neutral scope.
- 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.
- Inspect the current standard, relevant code, and existing tests.
- Use a branch or fork for the scoped change.
- Keep reusable project records blank. Exercise task and agent workflows in temporary copies rather than adding sample work to the distributed ledger.
- Update affected documentation alongside behavior.
- Run the relevant verification and explain the result in the pull request.
python3 -I -B .SYSTEMX/scripts/release.py
bash .SYSTEMX/SYSTEMX.sh validate
python3 -I -B .SYSTEMX/scripts/release.py --check
python3 -I -B -m unittest discover -s .SYSTEMX/tests -v
git diff --checkFor 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.
Rebuild the distribution manifest after intentional source edits, then review it. Keep the blank-seed fingerprint review separate. GitHub Actions remains disabled in this repository and no beta workflow is published. Maintainers run applicable local release checks and retain the evidence; see the final beta review for the two 373-test macOS suites and their six documented skips. Check applicable Python and operating-system combinations, validate wheel contents, and test a real installation from the built package before publishing a tagged release. Put release IDs and change history in Versions and changelog, leaving the README focused on public adoption and the current beta prerelease notice. Current template source keeps published PDF/image references and reusable operating files. Film, audio, and paper-authoring tools belong to the separate production archive. The historical alpha.5 publication security tests describe the retired authoring component; they are not a current runtime test command. Build future publication drafts in their own workspace and preserve the exact identity of already published editions.
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.
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.
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.
.SYSTEMX · DOT SYSTEMX · Maintained by Wayne Tech Lab LLC · Repository · User manual · Prompt cookbook · MIT license
Beta 1.11.0-beta.4 prerelease — validate the selected release in your project. Release policy. Project records, configured commands, and verified evidence determine the state of each adopted project.
DOT SYSTEMX · User manual
1. Start here
- The Guided Folder: 4K walkthrough and visual chapter index
- Start with a Folder: 4K animated guide
- Introduction video and archived poster
- Advanced walkthrough: inside the coordination layer
- Choose a workspace
- Agent 0 roster: roles, bots, and CLI paths
- Agent 0 and toolchain direct I/O
- First-time setup
- Provider and harness onboarding
- Daily workflow
- One-shot project guide
- Shared workspaces, clouds, and bots
- Historical use-case workflows
- Four current system maps
- Current maps, seven agent guides, and atlas
- Agent guide text and CLI flows
- Visual guide and historical diagrams
- New chat setup prompt
- Prompt cookbook
2. Work and continuity
- SYSTEMX PROJECTS
- AUTOBOT and Agent Alpha: Tier 2
- Local DATA storage
- Planning and memory
- ROOT planning, rules, and task delta
- System MAP
- Access Matrix: 20 standard entries
- Agent Beta, Agent1, and Agenda
- Task workflow
- Agent X: events and time
- Agent Y: CLI and PR channels
- Agent Z: fixed review
- 100 review questions
- Agent 0 and subagents
- Subagent processing
- Advanced use cases
- Evidence and acceptance
- Anti-drift and long-running work
- Tokens, cost, and time
3. Setup and maintenance
- Project / VS Code
- OS directory
- Google Drive
- LLM chat
- Exact casing and alias
- Installation and updates
- Upgrading
- Uninstall and cleanup
4. Advanced reference
- Standard format
- Technical Guide
- Stack Guide
- Library integration
- CLI and Tools
- Command reference
- Configuration and quality
- Operations and troubleshooting
- Security and support
- Code review and readiness
5. Project information