v0.3.6

Wind v0.3.6 — Work arrives anchored: wind up review cuts a review seat on a PR's head with the PR recorded in the manifest, and wind eval publish ships eval results to Wind Stream stamped with the session, branch, and commit that produced them.

Install

This repository is private during pipeline bring-up; install via gh:

# pick your build: wind-darwin-arm64 / wind-darwin-x64 / wind-linux-x64 / wind-windows-x64.exe
gh release download v0.3.6 --repo windstreamai/wind-cli -p 'wind-darwin-arm64' -p SHA256SUMS
shasum -a 256 -c <(grep darwin-arm64 SHA256SUMS)
chmod +x wind-darwin-arm64 && sudo install wind-darwin-arm64 /usr/local/bin/wind
wind setup

What's new

wind up review — start a review with the PR already loaded

Reviewing a pull request meant assembling the seat by hand: find the PR, fetch its head, cut a branch, open a session, then explain to that session what it was looking at. Now the PR is the only thing you supply.

wind up review --gh 907
# or paste the link
wind up review --gh https://github.com/acme/app/pull/907

start review session "907-groups-ui-polish" (from PR #907: "Groups UI polish")? [Y/n]

You land in a fresh worktree checked out on the PR's code — branch review/907-groups-ui-polish, named from the PR's own title — with the PR recorded in the session manifest. The Wind Stream session then opens already knowing which PR it's reviewing, what the description says, and which files it touches, instead of asking you.

Name the seat yourself by adding a slug (wind up review --gh 907 auth-paths). The PR number stays in the name either way, so the PR is identifiable from the branch alone and two reviews of the same PR can never collide.

Anything off is refused by name before a single file is created: a PR URL from a different repo (it names both repos and the fix), a PR already merged or closed, or a seat name that's taken.

One rough edge to know about: wind down doesn't understand review seats yet. Its summary reads the branch's commits — on a review seat those are the PR author's work, not yours.

wind eval publish — eval results that remember where they came from

An eval score is only as useful as your ability to trace it back to what produced it. wind eval publish ships an eval envelope file to Wind Stream and stamps every run in it with the context it came from — the Wind Stream session, branch, commit, release, repo, and who ran it — so a number you're looking at next month still points at the code behind it.

wind eval publish results.ndjson

delivered: 42 events → eval:asset-tagging (batch b_9fQ2xK, durable)

Run it inside a wind session and the stamps come free. Run it from CI, or any checkout without a session, and wind fills in what it can from git — then tells you plainly what it couldn't, rather than quietly shipping a gap:

provenance absent: ws_session_id (no wind manifest)
delivered: 42 events → eval:asset-tagging (batch b_9fQ2xK, durable)

Stamps your file already carries are never overwritten, so a CI sender that sets its own provenance keeps it. Every line wind doesn't stamp reaches Wind Stream byte for byte.

The exit code tells you the truth about delivery, which matters most when nobody's watching:

• 0 — Wind Stream durably committed every event. Only then.
• 1 — something was rejected, with each bad event named and numbered.
• 2 — the batch is spooled locally and still pending, not lost and not landed.

In CI there is no "pending": wind retries a few times and then fails outright. A green build never means data that quietly didn't arrive.

Docs

• Getting started — the guided walkthrough
• Command reference — every verb, its flags, and how it exits
• Install · Windows · Troubleshooting

Provenance

Built and published by the wind publish pipeline from windstreamai/wind
tag v0.3.6, commit 8d54fd07d83004e1274ae9c792afe2c9f367a01c. Assets are
checksum-verified before this release is published (see SHA256SUMS).

License

Proprietary — see EULA.md, governed by the
Wind Stream Terms of Service.
Third-party notices: THIRD_PARTY_NOTICES.md.