Configuration and Quality

Configuration and quality

SYSTEMX runs the commands your project defines. The shipped configuration is empty so it can fit different languages and delivery environments.

Initialize and configure

bash .SYSTEMX/SYSTEMX.sh init

Edit .SYSTEMX/project.json. This example is for a project that already has the listed npm scripts and deployment script; it does not install or scaffold them:

{
  "schemaVersion": 1,
  "project": {
    "name": "example-project",
    "description": "Describe the project's purpose"
  },
  "checks": [
    { "name": "lint", "command": ["npm", "run", "lint"] },
    { "name": "tests", "command": ["npm", "test", "--", "--run"] }
  ],
  "commands": {
    "dev": ["npm", "run", "dev"],
    "build": ["npm", "run", "build"],
    "deploy": ["bash", "scripts/deploy-project.sh"]
  }
}

A Python, Go, Rust, Swift, documentation, or infrastructure project supplies its own command arrays. Empty arrays leave actions unconfigured. Check names must be unique, and every configured check needs a nonempty command.

How execution works

Root commands run as argument arrays from the outer containing project directory. A selected child's commands run from .SYSTEMX/Projects/NAME, beside its .SYSTEMXP/project.json; recorded external source URLs do not change the CWD. Preview with systemx projects --target OUTER_DIR -- check --project NAME --dry-run when using a managed alpha.5 installation. CLI and Tools explains shared tool routing and the compatible local launcher. Shell operators, redirects, glob patterns, and $VARIABLE expressions are not automatically expanded. Use a reviewed project script when a workflow needs shell orchestration.

Commands inherit the current environment. Keep credentials in the appropriate environment or secret manager, not command arguments or project JSON. Arguments are displayed in command plans, including dry runs. Configuration is executable project input and must be reviewed before use.

Preview, then run

bash .SYSTEMX/SYSTEMX.sh doctor
bash .SYSTEMX/SYSTEMX.sh check --dry-run
bash .SYSTEMX/SYSTEMX.sh check

doctor checks whether the configured executables are available. A dry run validates records and prints the plan; it executes no project commands. A real check runs configured commands in order and stops at the first failure.

build adds the build command after checks. deploy adds build and deployment after checks. The project deployment script owns target selection, authentication, release policy, and any required confirmation.

Choose evidence appropriate to the change

Change	Useful verification
Documentation/configuration	Parsing, links, accurate examples, and rendered output
Business logic	Focused regression tests and relevant boundary cases
API/data contract	Compatibility, validation, partial failure, and migration checks
User interface	The affected journey in the actual target surface, including accessibility
Authorization	Positive and negative permission cases and isolation boundaries
Release/infrastructure	Intended target, reproducible artifact, smoke checks, and recovery evidence

Record the command, revision, environment, result, and evidence location with the related task. Label skipped checks and their reasons. Choose useful checks instead of adding a broad test list that does not establish the requested behavior.

Template checks versus project checks

bash .SYSTEMX/SYSTEMX.sh validate
python3 -I -B -m unittest discover -s .SYSTEMX/tests -v

These validate the template and its command behavior in isolated fixtures. They do not test the adopted application or its cloud services. Application quality is established by the real checks configured for that project.

For a pristine public distribution, additionally run validate --template. It checks only the distribution inventory and reviewed blank seeds; it is expected to reject initialized projects. See Standard format. For scoped source, deployed, functional, and operational claims, use Evidence and acceptance.

See the local quality standard for the evidence contract and the security standard for credential and execution boundaries.

Explicit AUTOBOT calls from tools

An integration may make an explicit Tools step select relevant AUTOBOT detail for a task. Use the documented commands and actual selected scope; do not turn the panel into automatic startup work, recursive check hooks, or a second policy engine. Request/result fingerprints support unchanged reuse while preserving original proof. Actual check/dev/build/ deploy tools still use reviewed argument arrays and the host's permissions. Audit local DATA exclusions before deciding to publish files.