mirror of
https://github.com/max-sixty/worktrunk.git
synced 2026-09-14 20:00:38 +08:00
Worktrunk Bot
29fa13dc95
Addresses the first, gating step of option #1 (SignPath Foundation) from #3355 — the fix for the `Trojan:Win32/Wacatac.B!ml` false positive on the unsigned Windows binary. ## What this PR does Adds a **code signing policy** page at [worktrunk.dev/code-signing/](https://worktrunk.dev/code-signing/). A published policy page is a hard eligibility requirement for the [SignPath Foundation](https://signpath.org/terms.html) free OSS code-signing program, so it's the natural thing to land first — the application can't proceed without it. The page documents: - **Certificate provenance** — the required attribution ("Free code signing provided by SignPath.io, certificate by SignPath Foundation") and the HSM-held key. - **What's signed** — `git-wt.exe` in the Windows release archive / winget; nothing else. - **The build+sign pipeline** — tag-triggered, cargo-dist on GitHub runners, SignPath action for signing, all reproducible from public source. - **Project roles** (Author / Reviewer / Approver), **per-release manual approval**, and the **no-telemetry** privacy stance SignPath asks projects to state. The generated skill mirror (`skills/worktrunk/reference/code-signing.md`) and `docs/static/llms.txt` entry are produced by `test_docs_are_in_sync` — not hand-edited. > **Roster check:** the roles table lists @max-sixty as Author/Reviewer/Approver. Adjust if anyone else should hold signing authority before this is submitted to SignPath. ## What this PR deliberately leaves out The `release.yaml` signing job and the SignPath account are a **follow-up**, for two reasons: 1. **The concrete slugs don't exist yet.** The SignPath action needs `organization-id`, `project-slug`, and `signing-policy-slug` — all issued *after* the project is registered and approved. 2. **cargo-dist doesn't sign natively, and the wiring is checksum-sensitive.** cargo-dist generates a per-artifact `.sha256` in the *local build job*, alongside the `.zip`. Signing the binary afterward means the signed `.zip` no longer matches its checksum, so a correct job has to sign → re-zip → **regenerate the `.sha256`** → overwrite the artifact before the `host` job uploads it. I don't want to ship that against a live release pipeline without being able to run it end-to-end (it only runs on a version-tag push), so it belongs in a follow-up gated behind the real SignPath config. I've laid out the exact maintainer steps and the proposed job shape in a comment on #3355. ## Verification - `cargo test --test integration test_docs_are_in_sync` — green (regenerates + validates the skill mirror, llms.txt, and Zola link transformation). - zola build + lychee link check run in CI (`check-docs`); neither tool is installed in the tend sandbox. Closes nothing on its own — #3355 stays open until signing is live. ## Follow-up commits on this branch - **`docs/static/code-signing.md` companion symlink** → `skills/worktrunk/reference/code-signing.md`, matching every existing page, so the `worktrunk.dev/code-signing.md` entry in `llms.txt` resolves once deployed. Also swaps a dead `opensource.axo.dev/cargo-dist` link for the repo's `axodotdev.github.io/cargo-dist` convention. - **`.config/lychee.toml` exclusion** for the self-referential `worktrunk.dev/<page>.md` links in `llms.txt`. Those point at the live site, so a brand-new page's entry always 404s in the link check until the site is deployed — a bootstrap gap every new-docs-page PR hits. Their existence is already guaranteed by `test_docs_are_in_sync`, and prose/template links use the trailing-slash form (`worktrunk.dev/faq/`), so the exclusion is scoped to the `llms.txt` index entries only. --------- Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: worktrunk-bot <worktrunk-bot@users.noreply.github.com>
30 lines
2.3 KiB
Plaintext
Generated
30 lines
2.3 KiB
Plaintext
Generated
# Worktrunk
|
|
|
|
> CLI for Git worktree management, designed for parallel AI agent workflows.
|
|
|
|
Worktrunk is a CLI for git worktree management, designed for running AI agents
|
|
in parallel.
|
|
|
|
Worktrunk's three core commands make worktrees as easy as branches.
|
|
Plus, Worktrunk has a bunch of quality-of-life features to simplify working
|
|
with many parallel changes, including hooks to automate local workflows.
|
|
|
|
## Commands
|
|
|
|
- [wt switch](https://worktrunk.dev/switch.md): Switch to a worktree; create if needed.
|
|
- [wt list](https://worktrunk.dev/list.md): List worktrees and their status.
|
|
- [wt remove](https://worktrunk.dev/remove.md): Remove worktree; delete branch if merged. Defaults to the current worktree.
|
|
- [wt merge](https://worktrunk.dev/merge.md): Merge current branch into the target branch. Squash & rebase, fast-forward the target branch, remove the worktree.
|
|
- [wt config](https://worktrunk.dev/config.md): Manage user & project configs. Includes shell integration, hooks, and saved state.
|
|
- [wt step](https://worktrunk.dev/step.md): Run individual operations. The building blocks of wt merge — commit, squash, rebase, push — plus standalone utilities.
|
|
- [wt hook](https://worktrunk.dev/hook.md): Run configured hooks.
|
|
|
|
## Reference
|
|
|
|
- [Extending Worktrunk](https://worktrunk.dev/extending.md): Three ways to add custom behavior: hooks for lifecycle automation, aliases for reusable commands, and custom subcommands for standalone tools.
|
|
- [LLM Commit Messages](https://worktrunk.dev/llm-commits.md): Generate commit messages from diffs using any LLM. Integrates with wt merge, wt step commit, and wt step squash.
|
|
- [Agent Integration](https://worktrunk.dev/claude-code.md): Worktrunk plugins for Claude Code, Codex, OpenCode, and Gemini CLI: a configuration skill, wt list activity tracking, and Claude-only worktree isolation.
|
|
- [Tips & Patterns](https://worktrunk.dev/tips-patterns.md): Practical recipes for Worktrunk workflows: aliases, shell integration, Zellij layouts, and parallel agent patterns.
|
|
- [FAQ](https://worktrunk.dev/faq.md): Common questions about Worktrunk: comparison to git worktree and branch switching, bare repos, TUI support, and more.
|
|
- [Code Signing Policy](https://worktrunk.dev/code-signing.md): How Worktrunk's Windows release binaries are code-signed: certificate provenance, the build and signing pipeline, project roles, and per-release approval.
|