v0.4.1

Wind v0.4.1 — Public distribution readiness.

Install

macOS / Linux (Homebrew)

brew install windstreamai/tap/wind

Windows (direct download)

Download wind-windows-x64.exe
and SHA256SUMS.
Follow the Windows install guide to verify it and add it to PATH.
The winget listing is pending.

After any install: wind setup deploys the Wind Stream integration.

What's new

Ready for public distribution

This release adds public install paths for wind. On macOS or Linux, use Homebrew:

brew install windstreamai/tap/wind
wind setup
wind --version

For Windows, download wind-windows-x64.exe and SHA256SUMS from this release
and follow the Windows guide.
The winget listing is pending a separate submission and install verification.

If you previously installed wind by hand, check type -a wind before switching to
Homebrew: an older copy earlier on PATH can hide the new install. Move that copy
aside, confirm the Homebrew binary is selected, and run wind setup again.

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.4.1, commit db0b59c91d655f66fdc67ce644e0b459814b3e7f. Assets are
checksum-verified before this release is published (see SHA256SUMS).

License

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

v0.4.0

Wind v0.4.0 — wind down is easy by default: it drafts the retrospective from your own work, shows what it verified, and records only when you say down.

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.4.0 --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 down writes the first draft

Finishing a piece of work used to end with an interview. Now wind down reads what this seat actually did, its own pull requests and the agent sessions bound to the worktree, and hands you a retrospective to approve:

wind down

Under the draft it shows what it checked and what it could not, in lines like these:

wind checked:
verified: 2 PRs — 1 merged, 1 open
transcript: 1 agent session read

Then it asks anything to add? with three choices: Down (record), Add something, Cancel. Each addition is folded into the draft and shown again. Nothing is recorded until you say down.

Two things to know. Cancel records no retrospective, but the draft exchange stays on the session as context. And the interview is still there when you want it:

wind down --interview

Upgrade note: a bare wind down used to open the interview and now opens the draft. --easy still works and does nothing, so existing scripts keep running, and --yes and --message no longer need it.

Inside a coding agent, you approve in the conversation

When a coding agent runs wind down there is no menu for anyone to answer, so wind records nothing and gives the agent a brief instead: the shape to write to, the facts it verified, and the command to record with. The agent shows you the whole draft and asks anything to add? You say down, and only then does it record, exactly what you approved:

wind down --message-file <path>

The approved text travels as a file, so nothing in it is expanded or mangled by a shell on the way. The file must be a regular file of at most 1 MiB. /windstream-feature-wrapup runs this loop for you. Anything other than down ("looks good", "ship it") is treated as an addition or a question, never as approval.

The exit code says whether your words arrived

A retrospective that could not be delivered is saved and sent later. Until now you had to read the closing lines to know which happened. Now the exit code tells you:

Exit	Meaning
0	Delivered to Wind Stream
2	Saved on this machine, not yet sent. It syncs at a later session start
1	Nothing saved

On a 2 the receipt names the entry, so you can send it yourself:

offline — saved, will sync on a later session start (session-…)
1 turn pending — will sync on a later session start
`wind sync session-abc123-2026-10-04T11-51-07-964Z-97088-0000` delivers it now

Upgrade note: before 0.4.0 a saved-but-unsent retrospective exited 0. A script that treats any non-zero exit from wind down as failure should treat 2 as safe and pending. Do not run the command again on a 2: that records the retrospective twice.

wind knows when an agent is calling

A terminal opened inside a coding agent is the agent's terminal, and a question asked there never gets an answer. wind now works out once per run who is calling (you at a terminal, a coding agent with you in the loop, or nobody) and behaves accordingly: full-screen views for you, plain text for an agent or a script, and no prompt that would hang. Force it either way from any position with --tui or --no-tui.

Every command also says what it does to the world. wind --help carries a read or write beside each command, and each command's page states its effect, so an agent can tell which commands leave nothing behind before it picks one. And the two status reads answer in JSON:

wind status --json        # tool readiness, upload-queue counts, how wind saw this run
wind sync status --json   # every queue entry with its state, reason, and next action

The upload queue, live

wind sync in a terminal now opens a view of everything waiting to upload, with the worktree each entry came from and what to do about it. Select with the arrows, then s syncs all, r retries one, b points an entry at a different session, h moves an entry to the host you are configured for, and d discards one. Host changes and discards ask first.

wind sync            # the live view, and it starts uploading
wind sync status     # the same view without sending anything
wind sync --plain    # line-by-line receipts, as before

One broken entry no longer blocks the rest. Previously a missing payload stopped the whole pass and left every later upload untried.

The software factory, in the binary

A Wind Stream brief becomes a gated, evidenced pull request handed to a reviewer. The lane that does this for Wind Stream's own repositories now ships inside wind, so any repository can run it:

wind factory install     # write the workflows, hooks, and agent definitions into this repository
wind factory selftest    # run the lane's eleven self-tests
wind factory health      # check both credentials and say which one is wrong

A person writes the brief and a person merges. The setup has real steps (a bot account, three secrets, a protected factory-build branch), and the guide walks through them: see docs/factory.md. The verbs need bash and python3, and use gh, curl, and jq. On Windows they run under WSL, and install from PowerShell is untested. On macOS, intake and sweep need Homebrew bash 4 or later and GNU coreutils.

Two supported coding agents

wind now supports Claude Code and Codex, and Antigravity support is removed. If Antigravity was your default, wind tells you so instead of failing later. Pick one and set it up:

wind agent claude    # or: wind agent codex
wind setup

wind next is removed

wind next, introduced in 0.3.9, is gone. Repository state alone could not say what the right next action was, and the command saw no real use. Nothing replaces it in this release.

Security fixes worth upgrading for

wind down cannot record a draft you have not seen. If you typed down while a draft was still being generated, wind took it as approval of text that had not reached the screen yet. Anything typed before a draft is shown is now ignored.

wind down --yes no longer records your transcript when it cannot draft. Offline or with an expired token, the unattended fallback used to include what you had typed to your coding agent. It now records the reason and the verified facts only.

A repository cannot point wind down at another worktree's sessions. wind reads the agent sessions of the directory its manifest is actually in, not the directory the manifest claims.

No more keychain prompts under a different home directory. Run inside a sandbox, a container, or a test harness that sets HOME, wind on macOS could trigger a system dialog offering to reset your keychain. It now leaves the keychain alone unless HOME is your account's own home.

A queue file in a repository can no longer reach outside it. wind reads its upload queue from your home directory and also from the repository you run it in. A repository carrying a crafted queue file could make wind write a file outside its own folder, or upload a local file the queue entry pointed at, the next time you ran wind status or started a session there. Both are closed: wind refuses the entry and lists it as unreadable. Earlier versions are affected too, so this one is worth upgrading for.

If you have not met wind proxy yet

wind proxy arrived in 0.3.10 without an introduction on this page. Here is the one it should have had.

You have two versions of a service: the one you run today and the one that should replace it. Point your application at wind proxy instead. It answers every request from one of them (the serve upstream), quietly asks the other (the shadow upstream) the same question, and counts where they differ. Wind Stream scores the window on /evals as <service>-window-parity: how many calls diverged, how much of the traffic was actually compared, and whether enough calls were seen to mean anything.

One command, one file.

wind proxy init id3 --serve http://localhost:7001 --shadow http://localhost:7002 --route "GET /tags/:id"
wind proxy run

init registers the service with your organization and writes wind-proxy.json. run serves on http://localhost:8787 (change port in the file). Point your app there.

Custody policy — your choice.

When two answers differ, the proxy keeps a divergence fixture. Where it goes is your organization's custody policy:

Mode	Where the fixture goes
windstream	Your Wind Stream organization, as an asset you can attach to the Outcome that closes the divergence
local	A directory on the machine running the proxy (./wind-proxy-divergences unless the policy names one)
none	Nowhere; only the field names and counts are kept

The proxy never loosens the policy on its own. If the policy says windstream and the platform is unreachable, the fixture is not written to disk as a fallback; the divergence still counts.

Record the truth, replay it against the candidate. A parity window needs the same questions asked twice. wind proxy record captures a service's answers as a set — <slug>-set/ with manifest.json, inputs/, and expected/ — over http (a paths file) or exec (a command run once per input file). wind proxy replay issues the set against the candidate and compares where the set carries ...

v0.3.10

Wind v0.3.10 — Wind can now move a verified proxy test set through Wind Stream and replay one exact version against a candidate service.

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.10 --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

Replay the exact version you tested

A recorded proxy set can now move through Wind Stream without becoming a moving target. Push the set once, pull the exact version you need, and replay that version against the service you are considering:

wind proxy push id3-set --config wind-proxy.json
wind proxy pull <set-id> --version <version-id> --out ./id3-baseline
wind proxy replay --set <set-id> --version <version-id> --against http://localhost:7002 --service id3 --window release-check

Wind verifies the manifest and payload digests before it writes a download or sends candidate requests. There is no latest selector, so a concurrent upload cannot change the set you are replaying. If a network response is lost after an upload succeeds, rerunning the same push resumes the same version rather than creating another one.

Ask Wind in plain language

wind ask now works with the live assist service. It maps an intent to a command and shows you the command; it never runs it:

$ wind ask "how do I upload a screenshot?"
  command  wind attach

The command descriptions sent for routing now fit the service limits, and an explicit question has enough time to receive an answer. Ambient suggestions remain quiet when Wind has nothing useful to add.

Your connection files stay out of the way

wind connect now adds Wind's own session files to your repository's local Git excludes. A newly connected worktree stays clean, and a routine git add -A will not stage its session metadata.

Better operational evidence, when you opt in

Wind can preserve a content-free record of what happened when it consulted assist: answered, declined, suppressed by policy, or failed. The record survives a normal CLI exit and restart, and identifies the compiled build that produced it. Collection remains off until your organization enables it; this release only makes the client ready to report the outcome it actually experienced.

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.10, commit f1048d9481a20807c44e706179299b5cc9ec8a1d. 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.

v0.3.9

Wind v0.3.9 — wind now guards the boundary between your repo and everything it touches — and meets an imperfect command with a suggestion instead of a shrug.

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.9 --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

Attach the file you actually have — text, Markdown, logs

wind attach stopped being images-only. The plan, the notes, the service log — they upload as themselves, filenames and bytes preserved, and come back as readable references:

wind attach plan.md notes.txt service.log

One edge to know: text needs the Wind Stream server to speak it too, which arrives with the platform's next deploy. Against an older server, wind refuses that one file with a plain reason and keeps going with the rest — your images still land.

The upload queue explains itself

When a trace or retrospective can't deliver — too big, offline, token expired — it no longer vanishes into a spool you can't see. It waits with a reason, and you have a hand on it:

wind sync            # deliver everything that can deliver now, one receipt per entry
wind sync status     # what's waiting, why, and what to do — no network
wind sync drop abc1  # discard one entry, loudly, on purpose

wind status shows one line when anything is waiting, and wind down opens with your worktree's queue state — a running session is never told "nothing pending" while its own trace is still to come.

Upgrade note: entries spooled by an older wind are stamped with the old default host and will sit parked after this upgrade. Run WIND_HOST=https://alpha.windstream.ai wind sync once and they drain — same backend, nothing lost.

A typo gets an answer

$ wind statsu
unknown command: statsu
did you mean: wind status?

And when you know what you want but not what it's called, ask in your own words — wind resolves it to a command and shows it, never runs it:

$ wind ask "wrap this session up"
wind ask · "wrap this session up"
  guess    wind down
  usage    wind down [--easy] [--inline] [--yes] [--message <text>]

ask is deliberately absent from the command index for now — matching by meaning needs a platform capability that's still on its way — but the verb works today for anyone who types it, and wind help ask says plainly what it can and can't do yet.

wind next — the one thing to do now

$ wind next
wind next · feature/dark-mode
  state    4 commits on feature/dark-mode, not pushed
  next     git push -u origin feature/dark-mode

It reads the session manifest, your git state, and the PR — then names one action and the exact command. It never runs anything, and when it couldn't look somewhere (gh signed out, no repo), it says which signal it lost instead of pretending the answer is "nothing".

Ambiguous topics ask you, not a coin flip

wind surf "dark mode work" used to silently continue the closest-matching thread — or fork a duplicate on a phrasing difference, permanently, because Wind Stream sessions are write-forward. Now several matches ask:

"dark mode work" matches more than one thread:
  1) dark mode
  2) dark mode rollout
  n) start a new thread
which thread? [1-2, n]

Typing a thread's exact title skips the prompt entirely — naming a thread is choosing it.

Open anything by id

wind open session-8WPGoDHQ    # or an outcome-…, att-…, any Wind Stream id

Works from any directory — no session manifest needed. The id resolves to the right page server-side, arriving with the platform's next deploy; until then the browser lands on the Wind Stream app shell.

The boundary got harder

This release treats everything wind touches on your behalf with suspicion on your behalf: a committed session manifest is vetted before any part of it reaches a filename, a git command, or your terminal (a tampered value refuses loudly and never echoes its bytes); URLs are validated before a browser ever sees them, and Windows no longer routes them through cmd.exe; the words you type into a retrospective are never lost to a refusal — worst case you get them back to copy.

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.9, commit c884d843617e19429f4593d63b5504429e493ff8. 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.

v0.3.8

Wind v0.3.8 — Pick your coding agent and keep the bracket: wind up now launches Claude Code, Codex, or Antigravity — with the full connect → trace → retrospective loop operational on Codex — and every SessionEnd trace carries metadata.provenance v1: what produced this work and what it took.

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.8 --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

Pick your coding agent — wind agent, wind up --agent

The wind bracket used to mean Claude Code, full stop. Now you choose the agent and the bracket follows:

wind agent codex          # persist your default
wind up v0.4.0 dark-mode  # opens the seat in Codex
wind up feature spike --agent claude   # one-off override, any wind up form

claude, codex, and antigravity are the three choices. Nothing to migrate: with no preference set, wind launches Claude Code exactly as before.

One edge to know: the agent is resolved before anything is created, so a bad preference or a missing credential refuses up front — you'll never find a fresh worktree stranded behind a launcher that couldn't start.

Codex runs the whole loop

Selecting Codex isn't just a launcher swap — the full Wind Stream bracket works: wind setup configures Codex's native MCP and lifecycle hooks and installs the $windstream-connect skill, sessions open connected, and when Codex exits your session trace is uploaded by the waiting wind up process, so the return path fits inside Codex's strict hook time budget.

Your Wind Stream token never lands in a Codex config file or a command line — Codex reads it from the child process environment, and wind auth login knows which agent's configuration to reconcile.

Two edges to know: Codex asks you to trust the installed hooks once (run /hooks inside Codex — setup installs them but can't trust them for you), and on the Wind Stream side a Codex trace currently displays under the Claude Code integration label until the server presents agents neutrally. Antigravity launches too, but as a launcher only — its return path is a later train.

Your trace says what produced it — and what it took

Every session trace now carries provenance: which harness and model did the work, the billing context it ran under (billing mode, whether an API key was present — never the key itself, and whether fast mode was on), and the git context it came from. Wind ships the raw signal; the platform turns it into pricing and reporting.

The full list of what a trace contains — everything, up front — is documented in docs/trace.md.

Frame an Outcome across several eval families at once

wind eval outcome frame char-empathy char-rigor char-wit \
  --statement "Opus 5 character holds across families" \
  --exit-condition "all six families green two eras running"

Every listed family binds to the one Outcome at birth, in order. And when an era closes, next inherits: run it with no list and the successor re-links everything the prior linked — the same lines, one era richer. Pass an explicit list only when you mean to restate the full set — the list you pass is the successor's set, so a family you omit is dropped on purpose.

If a bind fails partway, wind tells you exactly where things stand — linked so far, failed, not attempted — instead of leaving you to guess.

wind up inside a worktree no longer buries the new one

Running wind up from inside an existing worktree used to nest the new one at worktrees/worktrees/… under a mangled name. Now wind notices and offers the fix:

this is a worktree of ~/Developer/GitHub/wind — new worktrees would nest under ~/Developer/GitHub/worktrees/worktrees
anchor to the main checkout (~/Developer/GitHub/wind)? [Y/n]

Enter (or Y) puts the new worktree where it belongs, as a sibling under worktrees/ with the real repo name. n keeps the old behavior on purpose. Scripts and agents get the anchor automatically — announced, never silent.

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.8, commit e9d32c1b419ce10047eb06b0efacafccfcfef7c1. 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.

v0.3.7

Wind v0.3.7 — The CLI explains itself, and evidence rides with the work: every command now answers --help with its own page under a curated root index, and wind attach puts image evidence into the bound Wind Stream session's custody with a paste-ready link.

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.7 --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

Ask any command for help — wind <command> --help

Learning a wind command used to mean guessing, running it wrong, and reading the error — asking for help was the one thing guaranteed not to work. Some commands rejected --help as an unknown flag, and a few ignored their arguments entirely: wind setup --help didn't print help, it ran setup. Now every command answers for itself, and asking about a command can never run it.

wind down --help

wind down — Write a retrospective for this session

Usage:
  wind down [--easy] [--inline] [--yes] [--message <text>]

  The retrospective is written back to the attached Wind Stream session.

Flags:
  --easy    quick auto summary, approve/edit it (skips the interview)
  --inline  line-by-line rendering, no full-screen takeover (run it inside Claude Code)
  --yes     with --easy: record the generated summary without prompting
  --message with --easy: record the given text verbatim — supplying it implies acceptance

wind help down and -h answer too, anywhere in the arguments — the same shapes git and gh accept.

The front door slimmed down to match. wind --help had grown into a wall of every variant and flag; it's now a short grouped index — Core, Setup, Additional, one line per command — with the detail one --help away.

Two edges to know about: a literal --help or -h anywhere in a command's arguments shows help rather than being read as a value (the same trade git and gh make), and wind hook — machine-invoked plumbing — stays out of the index on purpose, though wind help hook still answers.

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.7, commit 509547497d3ba23d4ec725a086bc5712bcd40155. 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.

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.

v0.3.5

Wind v0.3.5 — Don't make me check — finished.

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.5 --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

Provenance

Built and published by the wind publish pipeline from windstreamai/wind
tag v0.3.5, commit 3c0d8822af235e1d086e927df21370e0d751a032. 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.

v0.3.4

Wind v0.3.4 — Don't make me check.

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.4 --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

Provenance

Built and published by the wind publish pipeline from windstreamai/wind
tag v0.3.4, commit 8a5a2bcaba7e9d4870d7ba07645c2b959ad1cc6f. 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.

v0.3.3

Wind v0.3.3 — distribution release.

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.3 --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

Provenance

Built and published by the wind publish pipeline from windstreamai/wind
tag v0.3.3, commit 51dc04a696cabc4143b88854f306121e4c8cdd72. 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.