The problem launches actually have
Most launches fragment between the team that decided and the team that ships. The recommendation gets handed over with a Notion doc and a Slack thread. By the time the blog post ships, the support agents are reading a different paragraph than the sales reps, the website brief describes a slightly different product, and the internal FAQ answers questions nobody asked. Everyone is doing their best from incomplete inputs.
The fragmentation isn't a comms failure; it's an authoring failure. There's no single object that holds “here's the launch, here are all the audience cuts, here's why every line is the way it is.” Bushel's job is to be that object.
What Bushel is
A launch is a unit, not a folder. One Winnow recommendation becomes one Bushel launch, which produces one bundle of audience-specific artefacts. The launch object tracks state explicitly: draft while the team is iterating, shipped once the work is out. Generation is allowed only in draft; shipping freezes the bundle. Reverting to draft requires explicit confirmation — the friction is the audit signal.
Generation reads four things at once: the recommendation Winnow validated, the user stories that supported its delivery, the Bushel-relevant foundations (brand voice, audience personas, channel inventory, the launch playbook), and any launch-specific notes you've added. Every artefact in the bundle sees the same input frame — consistency across the nine cuts comes from the shared context, not from cross-pollinating the outputs.
The nine artefacts
Three audiences, three artefacts each, plus one external customer-facing trio. The catalogue is fixed at nine for v1 — not a pick-and-choose menu, not a "what would you like generated today" prompt. The discipline is in the constraint: every launch produces the same nine cuts so the team learns to think in nine voices from the first launch onward.
For the customer: a blog announcement (600–1,200 words), a customer email (100–250 words, written as the variant pair of the blog), and a website brief — a brief for the team to apply to the product / pricing pages, not replacement copy.
For support and sales: an internal agent-facing FAQ (4–8 Q&A pairs), an in-deal sales one-pager (150–300 dense words), and a five- to-eight-slide markdown deck for sales narration.
For the internal team: a cross-team Slack post (80–200 words), a cross-team email (200–400 words, variant pair of the Slack), and a cross-team FAQ (6–12 Q&A pairs).
The variant pairs — blog/email for the customer, Slack/email for the internal team — share their input frame deliberately. The pair is the same launch in two registers, not two attempts at the same artefact.
Provenance, twice
Every artefact tells you where it came from in two places. The on-disk file carries machine-readable YAML frontmatter at the top: the recommendation id, the user stories included, the foundations that framed the voice, the playbook, the model, the run id, the timestamp. The pipeline reads this; lint reads this; audit reads this.
The body of the artefact carries a human-readable footer marked with <!-- bushel:provenance --> that renders the same fields as plain markdown. When the artefact gets pasted into Notion, Slack, or a Google Doc and the frontmatter gets stripped, the footer survives — the trail back to the recommendation and the foundations stays with the copy wherever it lands.
Regeneration archives the prior version. When the playbook changes, when the brand voice gets a tweak, when the recommendation gets revised — re- running generation moves the existing bundle to .history/<run_id>/ with a manifest mapping each archived artefact to the run that produced it. Operators never lose copy; they can browse, restore, or compare versions through the filesystem.
How it fits
The CLI is the canonical surface for scripted and batch flows:
bushel init # scaffold a workspace bushel launch create <rec-path> # one rec → one launch bushel launch select <slug> # filter user stories bushel generate <slug> # full nine-artefact bundle bushel export <slug> # paste-ready directory or zip bushel launch ship <slug> # freeze the bundle
The Web UI handles the eyeball-and-distribute steps: per-artefact previews, Copy + Download buttons that surface the body-only markdown (frontmatter stripped, provenance footer kept), and a launch-level Download all (zip) for the whole bundle. Either surface talks to the same workspace — the CLI is the canonical path; the Web UI is the comfortable sidekick.
Both share bushel lint: a static health check that flags foundation stubs still carrying TODO scaffolds, malformed launch frontmatter, orphan recommendations, selected- but-missing user stories, and provenance mismatches. No LLM cost; safe to run from CI or a pre-commit hook.
Why this matters
A launch is the moment when the cultivation cycle becomes visible to the outside world. Winnow turns evidence into recommendations. Bushel turns recommendations into shipped artefacts. The delivery outcomes — what landed, what didn't, what customers actually said in response — flow back into Winnow's raw evidence stream, and the cycle closes through reconcile.
Done well, this is the practice that lets a team ship four launches a quarter without any of them drifting from the strategy they share. Bushel isn't the launch — the launch is the decision, the build, the customer conversation that follows. Bushel is the authoring scaffold that keeps every audience cut anchored to the same evidence the team did the work from.
The methodology view sits at methodology / launch → (Bushel as the principle); the implementation view sits at the open-source repository (Bushel as the tool). Either entry point lands you in the same model.
Getting Bushel
Bushel is open source under the same licence as Winnow and develops in the same Cultivate Method Toolset monorepo. The public Bushel repository ships with the v1 release; until then, the code lives alongside Winnow at the Cultivate Method Toolset repo and installs via editable pip.
Reference docs: README, CLI user guide, and Web UI user guide.