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.10+). 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.10 or newer (the requires-python floor in pyproject.toml).

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, including the prerequisites matrix that states what pip install covers and what each self-host topology still needs. 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.