Worked Yesterday / Getting started
From a test to useful evidence.
Set up once. Run tests. Review the evidence. Recheck with your approval.
1. Install your team's package
Contact SVÄRTA AI for commercial access. Use a trusted package matching your operating system and processor. The native CLI does not need the Swift compiler. This guide covers the 0.10 workflow; check your version and verified targets.
Verify and install the package
Save the archive and checksum together. Verify before extracting, replacing the placeholder with the actual filename:
# macOS
shasum -a 256 -c <archive>.tar.gz.sha256
# Linux
sha256sum -c <archive>.tar.gz.sha256
Extract it, open a terminal in the extracted folder and install without sudo:
bash scripts/install-cli.sh
Accept optional PATH/completion setup for Bash, Zsh or Fish, then open a new terminal.
worked --version
worked
worked opens the guided menu. If it isn’t on PATH, use ~/.local/bin/worked.
A checksum checks integrity, not the publisher’s identity. If macOS blocks your package, contact SVÄRTA AI; do not disable Gatekeeper.
2. Configure once. Run your tests.
In a trusted project, generate a proposal from your existing test scripts. Review its commands and collection scope before approving it.
worked config init
worked config show
worked config apply
worked test
Worked recognizes supported npm, pnpm, Yarn, Bun and Swift projects. It does not install dependencies or execute anything during setup. New Node configurations propose a focused scope: Git, approved project files and selected runtimes. Existing settings are unchanged.
Each project has its own history. Use --workspace /absolute/project/path to choose one explicitly. Worked cannot reconstruct yesterday without a saved reference.
Compare environments without running tests
Confirm a working baseline only after verifying that your environment works.
worked start
# After a change, or when something breaks
worked check
worked report
check captures and compares. report exports the saved comparison as masked Markdown; review it before sharing.
# Once you have verified the environment works again
worked good
3. Automate failure reports
worked run --name unit -- npm test
worked run --name e2e -- npx --no-install playwright test
Worked captures before and after execution. A pass with complete evidence saves the before snapshot as a reference. A compatible failure compares passing-before with failing-before; changes during execution are shown separately, without claiming causality. No matching reference? The report says so. Your command’s exit code is preserved, even if report writing fails.
Use a separate name for each suite. Reports stay beside the project’s database, or in your chosen --report-dir /absolute/reports. Raw output and command arguments are not retained. A passing test does not mark the whole environment as working.
Team shortcuts: configure once, run with worked test
worked config init
# Review and edit .worked.json
worked config show
worked config apply
worked test unit
Share .worked.json in your repository for named test commands, collection exclusions, watched paths and ignore rules. init never overwrites a file or runs a test. apply asks you to approve the settings; test separately asks before executing project code.
This focused Node example names your existing npm test command unit and imports its JUnit report. Configure your runner to write that report on every run first:
{
"version": 1,
"disabledCollectors": ["config", "disks", "homebrew", "launchd", "network", "npm-global", "packages", "processes", "system", "systemd"],
"runtimeKeys": ["node", "npm"],
"watchPaths": ["package.json"],
"ignore": [],
"defaultTest": "unit",
"tests": {
"unit": {
"command": ["npm", "test"],
"report": { "format": "junit", "path": "test-results/junit.xml" }
}
}
}
Run worked test for the default suite, or name one explicitly. Reapply edited configuration before running it. Project settings never re-enable collectors you disabled locally. Keep secrets out of this file and only approve trusted repositories. Use --yes for deliberate approval in trusted scripts, not to bypass review.
Include JUnit or Playwright results
Worked reads reports produced by your existing test runner; it does not generate them or run browser tests itself. Import a fresh report without a project shortcut:
worked run --name unit \
--test-report test-results/junit.xml --test-format junit \
-- npm test
For Playwright, configure its JSON reporter to write test-results/worked.json, then use --test-format playwright with that path, or the equivalent report entry in .worked.json.
Only outcome counts and up to 100 failing names are imported—not error messages, logs, screenshots or attachments. Missing, unchanged or malformed reports are marked unavailable. If requested results are unavailable, contain failures or runner errors, or contain only skipped tests, even an exit-zero command retains the previous reference. Worked still preserves the child’s exit code.
4. Investigate. Review. Verify.
Saved comparisons and failed test commands create an incident: fixed evidence, available results and explicit gaps. Later runs do not replace those facts. Give your chosen agent a model-neutral brief:
worked incident list
worked incident show INCIDENT_UUID
worked incident prompt INCIDENT_UUID
Replace INCIDENT_UUID with the full ID from the list or failure report. show presents the facts; add --json for structured data. prompt prints a model-neutral analysis brief for your chosen agent—it does not call a model or start an agent.
The brief includes a structured response template. Import the agent’s JSON recommendation, review any code changes separately, then explicitly rerun the original approved suite:
worked incident review INCIDENT_UUID --file review.json
# Review the recommendation and any changes first
worked incident verify INCIDENT_UUID
worked incident activity INCIDENT_UUID
review validates evidence references and saves recommendations as untrusted data—it never executes them. verify requires a matching approved project suite in the original workspace and asks again before execution. Outcomes distinguish a passing command, passing test report, failure and inconclusive evidence. A pass proves only the observed suite result, not root cause or a complete fix. No automatic repairs, baseline updates or incident resolution.
Verification runs with your permissions, not in a sandbox. Use external isolation when needed. The default direct-child timeout is 120 seconds; set --timeout 1..3600 for longer suites.
Use agent handoffs through API, Node or MCP
worked api incidents --workspace /absolute/project/path
worked api incident --workspace /absolute/project/path \
--incident INCIDENT_UUID
worked api incident-activity --workspace /absolute/project/path \
--incident INCIDENT_UUID
The supplied Node client 0.5 provides client.incidents(), client.incident(id) and client.incidentActivity(id). MCP exposes worked_incidents, worked_incident and worked_incident_activity. Select the worked_analyze_incident prompt with an incident_id in a compatible host. Review import and test execution are not exposed as MCP tools.
These reads use the same masked facts and presentation, require no write permission and remain available after license expiry. Use a full incident ID, never a moving “latest” selector. Inspect worked api capabilities when connecting older installations.
Review before sharing. Evidence is untrusted data, not instructions. Masking is best effort; your agent host may send results to its provider. Restrict the host’s tools independently—prompt wording is not a security boundary.
5. Watch for environment changes
After confirming a working baseline with worked good, try a single check or enable a schedule:
# One check, no background job
worked auto check
worked alerts
# Optional hourly comparison and local notifications
worked auto on --compare --notify --every 1h --yes
worked auto status
worked auto off
Monitoring is off by default. Repeated identical changes are suppressed; collection gaps still create alerts. Add --min-level high to raise the relevance threshold. Omit --notify for saved reports without local notifications.
macOS uses launchd; Linux uses a systemd user timer. One schedule per user, every 15 minutes to 24 hours. Sleep and user sessions affect runs. Linux notifications need notify-send and a graphical user session; OS permissions affect visible banners. These jobs compare environments, not run tests.
CI: keep references between runners
worked run --name unit \
--baseline-file /private-ci-storage/reference.json \
--baseline-key myproject.unit.ubuntu24 \
--report-dir /private-ci-storage/reports \
-- npm test
Restore the reference before a job and persist it after a successful run. Failed tests or incomplete evidence leave it unchanged. Serialize jobs sharing a file and separate projects and suites. A comparison requires compatible key, command, configuration, collection scope, branch, OS and architecture. An incompatible reference does not prevent your test command from running.
The portable file keeps versions, packages and project-local Git/config evidence, excluding host identity, ports, processes and non-project configuration. It still contains names and hashes: use trusted, access-controlled storage.
In a custom GitHub workflow, add --github-summary to append a masked failure report to the job summary and configure caching/uploads explicitly. The supplied 0.8+ GitHub Actions integration handles references and optional report sharing in trusted private repositories; it is not a published Marketplace action. Its hosted cache/artifact flow has passed a private pilot, not a customer-project performance benchmark.
Connect VS Code, the API or MCP
Install your team’s VS Code extension through Install from VSIX, then run Worked: Show Status. Select the trusted CLI executable when prompted. Opening the editor does not collect data.
The local versioned JSON API and supplied Node.js adapter share the same project history. There is no HTTP server.
worked api capabilities
worked api status --workspace /absolute/project/path
worked api alerts --workspace /absolute/project/path
For a compatible MCP client, use an absolute executable and workspace:
{
"mcpServers": {
"worked": {
"command": "/absolute/path/to/worked",
"args": ["mcp", "--workspace", "/absolute/project/path"]
}
}
}
MCP runs over standard input/output and is read-only by default. It exposes status, collection scope, history, reports, alerts, fixed incidents, activity and the analysis prompt. Optional history writes require server opt-in and per-call confirmation; this is not permission to execute tests or apply fixes. Your MCP client may share results with its model provider.
Platform requirements
| Platform | Requirements |
|---|---|
| macOS | macOS 14 or newer, with a package matching your processor. The 0.10 CLI/API/MCP, review/verification flows and isolated license checks have passed on Apple Silicon. The local archive is unsigned and unnotarized; it is not a public signed release. |
| Linux | Core and team workflows in 0.8 passed full-system tests on Ubuntu 24.04 ARM64 and a hosted pilot on Ubuntu 24.04 x86_64. The 0.10 workflow is not yet validated on Linux. Use a native package matching your distribution/version and processor; glibc and SQLite are required. A systemd user session is needed only for optional scheduling. |
| Other systems | Native Windows and Alpine/musl are outside this release's supported scope. Do not use a Linux or macOS package on an incompatible system. |
Collectors recognize dpkg, RPM and pacman; this does not make one binary compatible with every Linux distribution. Unavailable sources produce visible collection warnings.
Collection scope and privacy
Worked stores structured metadata and fingerprints locally, not raw watched-file contents or environment-variable values. Approved Node manifests and version files supply selected requirements, pins and npm lockfile versions; other supported lockfiles supply fingerprints. These describe declarations, not proof of installed dependencies. Secret-like files are excluded by default. Inspect and choose collectors:
worked scope
worked scope disable processes
worked scope enable processes
No telemetry or automatic uploads. Reports are masked, not guaranteed anonymous: branch names, packages and other identifiers may remain. Review them before sharing. CI artifacts and MCP results follow your chosen provider’s access rules.
Alerts preserve the last manual comparison and the working baseline. The latest 100 are indexed by worked alerts; report files remain until explicitly removed.
Incidents retain up to 100 selected changes and 100 failing test names, with explicit omissions. Reviews and verification outcomes are append-only. Incidents and activity survive snapshot cleanup, are included in backups and have no automatic expiry. Old reports, passing runs and monitoring alerts are not converted into incidents.
Backups, updates and support
worked backup --output /absolute/path/history.sqlite3
worked support --output /absolute/path/worked-support.json
Use new filenames. Support exports contain operational metadata, not your inventory or license contents; nothing is sent automatically.
Update from a verified package with bash scripts/install-cli.sh --replace. The previous executable and history are retained. Signed-release packages also support worked update --from /absolute/path/extracted-package.
bash scripts/uninstall-cli.sh removes the executable and owned schedule, not history, backups or shell configuration.
Send your SVÄRTA AI contact the command, warning and reviewed support summary—not your raw database or license file.