go-schedule documentation
Audience: users and maintainers of go-schedule
Applies to: go-schedule 0.7.0 and later
Project home: README.md
An index of what is here and who each document is for. If you are installing, start with the guide for your platform; if you are contributing, start with CONTRIBUTING.md in the repository root.
Using go-schedule
| Document | What it covers |
|---|---|
| Windows install guide | The .msi, the service, PATH, upgrading, uninstalling. |
| Linux install guide | Release archive, systemd registration, data paths. |
| macOS install guide | Desktop bundle versus headless, launchd, and the boot-persistence caveat that catches people out. |
gosched command reference | Every command and flag the CLI exposes, with exit codes and elevation requirements. |
| Local API | Versioned completion-chain endpoints, error shape, correlated history, and live events. |
| Webhook notifications | Safe receiver payloads, reusable channels, task and group policies, retries, duplicate handling, and delivery evidence. |
| Local MCP access | Observe-only Codex setup, resource inventory, trust boundaries, bounds, and local IPC authorization. |
| GUI field reference | What every field in the desktop task editor accepts and means. |
| Cron interoperability | The documented five- and six-field subset, task authoring, operational crontab import, export, and named fidelity refusals. |
| Brand system | Approved identity, asset selection, accessibility, attribution, misuse rules, and downloads. |
Verifying an installation
| Document | What it covers |
|---|---|
| Maintainer test scripts | Proving that a real, installed daemon fires on time, survives restarts, catches up after downtime, and honors overlap policies, with recorded evidence rather than a hopeful glance at a log. |
These are written for maintainers but are equally useful to anyone who wants their install demonstrated rather than assumed. Their output makes an excellent attachment to a bug report.
Developing go-schedule
| Document | What it covers |
|---|---|
| Contributing | Trunk-based workflow, the spec-kit requirement, the CI-parity gates, pinned artifacts. |
| Build-phase autopilot | The protocol under which features are executed end to end with a single human halt. Maintainer-facing. |
| Architecture | Daemon ownership, durable completion delivery, replay semantics, and graph safety. |
| Constitution | The engineering principles the project is governed by. |
| Master specification | What the scheduler is and why, with the plan, data model, and contracts alongside it. |
| Changelog | Release history, including the dated decisions behind changes to pinned artifacts. |
| Canonical brand kit | Brand masters, outputs, tokens, platform assets, build source, and repository validation guidance. |
Reporting problems
Open an issue. The forms ask for version, component, install method, OS, and whether you were elevated, each of those has, at some point on this project, been the fact that decided the diagnosis.
For security issues, please use the private route described in SECURITY.md rather than a public issue.