workstate-bootstrap
Pip-installable CLI that hoists the shared workstate-system surface
(typed protocol, two MCP servers, hooks, skills, generated agent
workflows) into consumer repositories. Lives inside
darce/workstate.
Consumers run workstate-bootstrap install --target <path> once; it
clones the monorepo, materializes the overlay, and registers both
managed MCP servers (mcp-workstate-handoff, mcp-workstate-orchestrator)
across .mcp.json, .vscode/mcp.json, and .codex/config.toml. No
hand-edits required.
Install
From PyPI (recommended)
uvx --from workstate-bootstrap workstate-bootstrap install --target /path/to/your/repo
# or, persistent:
uv tool install workstate-bootstrap
From the monorepo source tree (development)
cd packages/workstate-bootstrap
python -m pip install -e ".[dev]"
Direct from git (private-repo phase, before PyPI release)
One-shot (no install — fetches each invocation):
uvx --from "git+https://github.com/darce/workstate@workstate-bootstrap-v0.2.1#subdirectory=packages/workstate-bootstrap" \
workstate-bootstrap install \
--target /path/to/your/repo
Persistent (recommended once you start running status / doctor
regularly — installs workstate-bootstrap onto $PATH):
uv tool install "git+https://github.com/darce/workstate@workstate-bootstrap-v0.2.1#subdirectory=packages/workstate-bootstrap"
# then:
workstate-bootstrap status --target /path/to/your/repo
workstate-bootstrap doctor --target /path/to/your/repo
# upgrade later:
uv tool upgrade workstate-bootstrap
Hardlink warning on first install? If you see
Failed to hardlink files; falling back to full copy, youruvcache and tool dir live on different filesystems. The install still succeeds; silence the warning withexport UV_LINK_MODE=copyin your shell profile.
Subcommands
workstate-bootstrap install --target <path> [--remote-ref <tag>] [--mcp-servers <default|path>] [--no-mcp-servers]
workstate-bootstrap update --target <path> --remote-ref <tag>
workstate-bootstrap status --target <path>
workstate-bootstrap doctor --target <path> [--mcp-servers <default|path>]
workstate-bootstrap repair --target <path> [--force-dirty] [--mcp-servers <default|path>]
workstate-bootstrap adopt-worktree [--target <linked-worktree>] [--primary <root>] [--check] [--json]
install: Clone the monorepo, materialize SHARED + GENERATED surfaces, write the three MCP-config files, runinit-stateto provision<target>/.task-state/handoff.db(skipped under--no-mcp-servers), setcore.hooksPath, and write the overlay manifest.update: Re-run install at a new--remote-ref; refresh GENERATED surfaces and, optionally, configs.status: Print a summary of the installed overlay manifest. When the install registered MCP servers, also reports the resolvedstate_dir/db_path/exports_dir/schema_versionviainit-state --check.doctor: Detect drift in SHARED, GENERATED, config, and initialized-state surfaces. Flags missing.task-state/handoff.dbasstate_driftonly when the manifest recorded.mcp.json. Exit1when drift exists.repair: Restore drifted surfaces flagged bydoctor. For an unadopted linked worktree this routes toadopt-worktree(below).adopt-worktree: Materialize the overlay into a linked git worktree by redirecting its surfaces at the primary's.workstate/remoteclone (one hop, relative links).--targetdefaults to the current directory; the primary is resolved by the.workstate-bootstrap.jsonmarker unless--primaryis given.--checkreports drift without writing and exits1when the worktree is unadopted. A no-op on the primary worktree.
Linked worktrees
A linked worktree (git worktree add, or an IDE/agent auto-worktree)
shares the primary's .git but not gitignored files, so the
overlay starts absent — the plugin is enabled (tracked
.claude/settings.json) but unresolvable. Self-heal works as follows:
-
make task-start(the supported flow) adopts the overlay into the new worktree automatically, so it works out of the box. In source checkouts, the lifecycle uses the freshly provisioned worktree.venvworkstate-bootstrapcommand when available, then falls back touvx. SetWORKSTATE_ADOPT_CMD=""to disable auto-adopt, or set it to a custom command to override that default. -
Post-provision bootstrap — after adopt,
make task-startcan also run a consumer-declared shell command (for examplenpm install) viaLIFECYCLE_WORKTREE_BOOTSTRAPin the rootMakefile. Best-effort, worktree-rooted,sh -csemantics; see the development-workflow rule doc. -
Raw
git worktree add/ auto-worktrees are healed on demand:uvx workstate-bootstrap adopt-worktree --target <worktree> # or, as a steady-state guard (exit 1 on drift): uvx workstate-bootstrap adopt-worktree --target <worktree> --check
.task-state/, DASHBOARD.txt, and CURRENT_TASK.json are never
adopted — they stay per-worktree (the handoff DB is primary-rooted).
See docs/CONSUMER.md
for the consumer-facing walkthrough (upgrade, drift handling, skill
overrides, the current_task_auto_regen migration note).
Surfaces written by install
The canonical source of truth for bootstrap-managed surfaces is the
installer implementation in
src/workstate_bootstrap/install.py (SHARED_SURFACES and
GENERATED_SURFACES). Keep this table aligned with those constants.
| Surface | Source | Layer |
|---|---|---|
scripts/hooks/ |
shared | symlink |
.github/hooks/ |
shared | symlink |
docs/workstate/contracts/ |
shared | symlink |
docs/workstate/rules/ |
shared | symlink |
Makefile.d/ non-excluded children |
shared | carved dir |
scripts/workstate/ non-excluded children |
shared | carved dir |
.github/prompts/ |
generated | real dir |
.workstate/generated/plugins/workstate-system/base/ |
generated | real dir |
.workstate/generated/plugins/workstate-system/effective/ |
generated | real dir |
.mcp.json |
generated | real file |
.vscode/mcp.json |
generated | real file |
.codex/config.toml |
generated | real file |
core.hooksPath git config |
generated | git config |
.task-state/handoff.db |
runtime | sqlite |
.task-state/exports/ |
runtime | dir |
.workstate/remote/ |
bootstrap | git clone |
.workstate-bootstrap.json |
bootstrap | manifest |
.task-state/ is provisioned by the handoff server's init-state
subcommand at install time and is gitignored — each fresh checkout
regenerates it through workstate-bootstrap install.
Defaults
--profiledefaults toall, which materializes the full surface set: generated Copilot prompts, Claude/Codex plugin trees, shared overlay surfaces, and the lifecycle hoist (Makefile.d/lifecycle.mkplus the sentinel-bracketed-includeblock in the consumerMakefile). Pass--profile minimalfor a clone-only install with no surfaces, or--profile lifecyclefor just the lifecycle runner and Makefile fragment. The active profile is recorded in.workstate-bootstrap.jsonunder"profile".--remote-urldefaults togit@github.com:darce/workstate.git.--remote-refdefaults tomain(override with a release tag likev0.1.0).--mcp-serversdefaults to the built-in managed map registeringmcp-workstate-handoffandmcp-workstate-orchestratorviauvxwith--workspace-root . serve-stdio, so Codex, VS Code, and Claude clients start real MCP stdio servers from the generated config. Pass a JSON file path to override; pass--no-mcp-serversto skip the three config writers entirely.- Plugin overrides are auto-discovered at
workstate-overrides/workstate-system/when that root contains anoverrides.yamlmanifest. Use--plugin-overrides <path>oninstall,update,doctor, orrepairfor a non-default root; bootstrap records that path so later update/doctor/repair runs reuse it. Override-aware installs generate effective plugin trees under.workstate/generated/plugins/workstate-system/effective/{claude,codex}and point marketplace pins at those generated trees. installandupdatepreserve plugin override files by default.--reset-overridesis the explicit destructive path; it removes only the resolved override root, refuses dirty git worktrees unless--backupis supplied, and archives backups under.workstate/override-backups/<timestamp>/before removal.
Development
Tests live under tests/. From the monorepo root:
cd packages/workstate-bootstrap
PYTHONPATH=.:src:../workstate-protocol/src pytest tests -q
Metadata
Release files for workstate-bootstrap 0.10.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| workstate_bootstrap-0.10.0.tar.gz | 116.7 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| workstate_bootstrap-0.10.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 239.0 kB
Release files / workstate_bootstrap-0.10.0.tar.gz
| Download URL | workstate_bootstrap-0.10.0.tar.gz |
|---|---|
| Size | 116.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
08c11d8d4d159efbe8265a2a3f49fb4a96307e7dc6d1c08dfabca314b9e0edf2
|
|
BLAKE2b-256 checksum How to use checksums |
b40fc108b10257df4910edfde4c542f85396c1c1af87137b2d9ffb17c809edf5
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jun 12, 2026.
Transparency logRelease files / workstate_bootstrap-0.10.0-py3-none-any.whl
| Download URL | workstate_bootstrap-0.10.0-py3-none-any.whl |
|---|---|
| Size | 122.3 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
fd5db93a12b7dff278cc9d189fe7a4419d6a1b60bbb92127111b154767b02419
|
|
BLAKE2b-256 checksum How to use checksums |
45166b2e4bdb971db3c1258149093ca3a33b644d15cf039ea21f5bac9b184c5c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jun 12, 2026.
Transparency log