Release: Wombat

Wombat is the current DocsHub architecture.

Read the Roadmap

StaxDash Organization Standards #

Version 1.0.0 Reviewed: 2026-08-28

The ZFordDev ecosystem root standards apply to every StaxDash repository. These StaxDash-specific standards extend — not contradict — that root, and cover the conventions of running StaxDash as a professional studio with an open core, paid tiers, and a contracting business.

Scope #

These standards apply to all repositories under the StaxDash identity (StaxDash/*). Where this document conflicts with the ZFordDev root standard, the root standard wins unless a StaxDash policy is explicitly stricter.

Licensing policy #

StaxDash is open source by default, commercial where it is sustainable:

• Open source core — StaxSys, StaxPing2, and the website are MIT licensed. These are the public face of the ecosystem and remain free, with no account or cloud requirement.
• Commercial products — StaxMonitor, StaxLens, and StaxSuite build on the open core and are licensed under their own terms (perpetual, per-node/per-seat licensing; hosted subscriptions; paid desktop modules).
• Every repository ships a LICENSE (or, for proprietary products, an EULA) and states its license in its README. Never reuse StaxDash code for a commercial product without checking its license.

Repository hygiene #

Per the ZFordDev root standard, every StaxDash repository carries:

.github/
├── CODEOWNERS
├── FUNDING.yml
├── SECURITY.md
└── ISSUE_TEMPLATE/  (when public contribution is open)

.gitignore
LICENSE  (or EULA.md for proprietary products)
README.md
temp_notes.md  (git-ignored, never committed)

StaxDash adds: every repository README must state, in the first few lines, what the tool does and what it does not do, and must list per-feature platform coverage.

Documentation standard #

• DocsHub is the source of truth. Product documentation lives in DocsHub/src/staxdash/ and is published at docs.staxdash.com.
• Repo READMEs and the website point to DocsHub rather than duplicating docs.
• Every docs page carries the front-matter fields required by the DocsHub checks (document_id, document_revision, applies_to, last_reviewed, category, status, weight, tags) and must pass npm run check.
• Using the Python, Go, JavaScript, and Markdown conventions in ZFordDev Standards that already apply.

Tooling conventions #

StaxDash tools are built to these shared rules:

• Small footprint — one runtime dependency or fewer where possible; prefer native OS APIs.
• Cross-platform — macOS, Linux, and Windows at minimum, native where it makes sense; the BSDs where practical.
• Honest platform coverage — state per feature whether it works on each OS.
• Test matrix — every repository runs a CI matrix on Linux/macOS/Windows (Node 18 and 22, or the project’s runtime) on push and pull request.

Release convention #

• Semantic Versioning (see the ZFordDev root standard).
• Tagged releases with release notes.
• Standalone binary builds for each supported OS, attached to the GitHub release, plus Homebrew tap and npm tarball where applicable.
• The DocsHub products.js registry and staxdash-terminal-index.js must be updated on documented releases so docs, the website terminal, and search stay current.

Merge discipline #

The ZFordDev root standard defines a lightweight but strict merge discipline (cooling period, full-functionality testing, no end-of-window merges, staging branch). StaxDash org adopts it as written, including the emergency hotfix protocol.

Security and vulnerabilities #

Every StaxDash repository ships a SECURITY.md explaining:

• How to report a vulnerability privately.
• Expected response and disclosure times.
• Any product-specific security considerations (e.g., signed binaries for on-prem agents).

Client engagement #

StaxDash takes on contracts for system tooling, monitoring, and integrations. The client engagement and support policy is documented separately under company and support. Contract work follows the same conventions: open source where the client agrees, honest scope, and documentation shipped with the tool.

Questions about these standards should be raised through the normal issue channels. Standards evolve as the studio grows; the ZFordDev root standard remains the default expectation where these are silent.