Workweaver

Workweaver turns a goal you state in plain language into finished work, with a receipt for every decision.

ww is the Alpha CLI for that product (Python 3.14). It remains the generic edge harness for Workweaver. One install covers knowledge work, coding, WorkMemory, and bidirectional ACP — the same pipe, not four products.

Install

python -m pip install workweaver

On Windows, use the Python launcher:

py -m pip install workweaver

The same wheel exposes ww, workweaver, and python -m workweaver. Requires Python 3.14.

If the ww script is not on PATH, run the module form:

python -m workweaver --help

pipx install workweaver is optional when you want an isolated CLI environment. Repo-local install (python -m pip install -e . from the repo root) still works for active development.

The edge harness

ww is the local command surface:

• Knowledge — goals, missions, skills, evidence, and receipts from the edge.
• Coding — local execution legs for governed coding work.
• WorkMemory — remember, recall, and forget through the same pipe as the rest of the harness. Writes queue locally when the API is unreachable and replay on sync.
• Bidirectional ACP — ww acp start serves Workweaver to editors and other agents; ww acp invoke drives invited agents. Workweaver is both component and orchestrator.

WorkMemory is not a second install or a second product. It rides the same ww pipe.

Start

ww login
ww memory recall "what did we decide last week"
ww acp start

ww login opens the Workweaver sign-in flow and works for both sign-in and sign-up. CLI session metadata and bearer tokens are saved in ~/.workweaver/config.yaml with file mode 0600 by default; the CLI does not touch the OS keyring unless an operator explicitly sets WW_ALLOW_KEYRING=1 and installs the optional keyring extra.

Self-host and first-run deployment paths live in docs/SELF-HOST.md. They are not the primary listing story.

Package

Live listing: https://pypi.org/project/workweaver/.

Releases are cut by tag through .github/workflows/release-pypi.yml using PyPI Trusted Publishing (OIDC). No API tokens live in the repo. Tags matching pyproject.toml pre-release versions (e.g. v0.1.0a1) publish to TestPyPI; final versions publish to PyPI.

Release operators use the guarded repo targets instead of hand-rolling tags:

VERSION=0.1.13 make release-python-prepare
VERSION=0.1.13 make release-python-check
VERSION=0.1.13 make release-python-tag
VERSION=0.1.13 make release-python-smoke-public

Validate a prerelease against TestPyPI:

python -m pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ workweaver

Then verify the installed CLI contract:

ww --version
ww memory --help
ww acp --help

Repository checks

Contributors validate infra cost posture with make cost-guard (offline fixed-floor register and Terraform resource review, also part of make check-meta); the contract it enforces lives in ops/cost/profile-cost-ceilings.json.

Canonical architecture and product truth live in:

• policy/docs-index.yaml
• docs/canonical/RUNTIME.md
• docs/canonical/PRODUCT.md
• docs/canonical/CLI.md
• docs/reference/runtime/acp-contracts.md

Repository development

Development targets are defined in the repository Makefile. The structural fixed-floor cost guard is enforced in CI and locally with make cost-guard.