Launch v0.7.0 → main: README rebuild + collateral + eBPF advisory

[vaderyang]

What

Brings the v0.7.0 launch content onto main: the GIF-first README rebuild, corrected PH/HN/Twitter collateral under launch/, the eBPF experimental/opt-in advisory (startup log + Settings toggle tag), and the v0.7.0 version bump.

Why a separate PR

The OTel rename was squash-merged to main on its own (#174), while the launch work landed on feat/otel-rename (#175). Because of the squash, main and feat/otel-rename diverged, so the launch content never reached main — main is still VERSION=0.6.0 with no README rebuild. Re-merging feat/otel-rename would re-apply the rename that's already on main.

This PR is the launch delta only, cherry-picked cleanly onto main (the launch changes touch different files than the rename — README, launch/, version files, main.rs advisory, settings.tsx — so it applies with no conflicts).

Verification

cargo check -p heron, console tsc -b + eslint, version-sync (0.7.0), and the infra-leakage gate all pass on this tree.

Release path

Once merged, main runs ci → deploy-staging → {staging-soak, ebpf-soak}. After both stamps land, tag that commit v0.7.0 to let release.yml cut the release.

Still owned elsewhere

• Marketing: re-cut the hero GIFs (drop --ebpf, bump to v0.7.0), finalize eBPF segment wording.
• Launch day (manual): GitHub Topics / Description / social preview; heron-ai.pages.dev landing page.

[github-actions]

The pcaps are in testdata/pcaps/corpus/, not directly in testdata/pcaps/. The README says "The repo ships fixtures in testdata/pcaps/ — replay any of them." This is slightly imprecise (they're in the corpus/ subdir) but not a blocker — a user will find them. Worth a Suggestion.

I have enough to write the review. Let me compile the findings.

The task reminder about TaskCreate isn't applicable — this is a single review pass with a fixed output format, not multi-step tracked work.

Summary

PR #176 is the v0.7.0 launch cut: a README rebuild (GIF-first, conversion-driven), new launch/ collateral (PH/HN/Twitter paste-ready copy), a VERSION/Cargo/package.json bump 0.6.0→0.7.0, a small eBPF discoverability nudge in main.rs (one tracing::info! line on Linux when no eBPF source is active), an "experimental" tag on the console Settings eBPF toggle, and a scrub of a real /home/v/... path from the eBPF uprobe tests to /home/user/... (the approved leakage-gate placeholder). No sensitive-information leakage, no schema/storage/capture-pipeline regressions, no TS↔Rust drift. The change is well-scoped and the code paths verify. Recommendation: APPROVE.

Suggestions

• server/app/heron/src/main.rs:374 — The eBPF advisory tracing::info! fires on every Linux startup that lacks an eBPF source, including the canonical --pcap-file capture.pcap --no-retention quick start and heron -i eth0 capture that the new README promotes. For a user who has consciously chosen libpcap/pcap replay, this is a recurring one-liner of "you're not using eBPF" on every run. Consider gating it to only fire when no capture source is active at all (i.e. a truly passive run), or downgrading to tracing::debug! / moving it behind a --help-eBPF hint — the discoverability goal is met without implying the chosen mode is incomplete.
• README.md:45 — "The repo ships fixtures in testdata/pcaps/ — replay any of them" is slightly imprecise: the .pcap files live in testdata/pcaps/corpus/, not directly in testdata/pcaps/ (which holds README.md, corpus.toml, and the corpus/golden subdirs). A first-time user following the link will land one level above the actual pcaps. Either point at testdata/pcaps/corpus/ or add a one-line "in corpus/" clarification.
• launch/PH_Submission_Details.md:44–48 — The Maker's First Comment claims "On-host eBPF capture … What's new in v0.7.0", but per CHANGELOG.md the eBPF SSL-uprobe capture shipped as a first-class soak-gated capability in 0.6.0 (and experimental since 0.5.1). What's actually new in 0.7.0 is only the discoverability advisory + the "experimental" UI tag — the capture itself is not new. Rephrase to "v0.7.0 makes eBPF capture discoverable…" or move the eBPF paragraph out of the "What's new" framing to avoid an inaccurate launch claim on Product Hunt.
• launch/HN_and_Twitter_Posts.md:18 — "We run Heron … on our inference fleet" + "~73% of Claude Code's opus-model calls in our capture" discloses a specific production-telemetry finding about a third party's CLI behavior. Not a leakage of your infra, but it is a claim that will attract scrutiny on HN ("show us the data"). Make sure the 73% figure and the "security monitor sidecar" characterization are reproducible / defensible before posting; if they're from a private corpus you can't share, expect pushback. (Also: the <block> mechanism described in line 20 — verify this matches the actual prompt-injection-blocking behavior of the released Claude Code version; it's presented as fact.)
• CHANGELOG.md:7–9 — ## [Unreleased] is now immediately followed by ## [0.7.0] with no body under Unreleased. That's valid Keep-a-Changelog, but if you intend to accumulate 0.7.1+ entries under Unreleased post-cut, the empty heading is fine; if not, removing the bare ## [Unreleased] line until the next change lands is tidier. Minor.

Questions

• launch/PH_Submission_Details.md:15 / launch/README.md:27 — https://heron-ai.pages.dev is listed as the Website URL for the Product Hunt submission, but launch/README.md:27 notes the landing page is "not in this repo … stand it up separately before launch." Is the pages.dev site actually live / owned by the org, or is this a placeholder that needs resolving before the PH submission goes out?
• launch/HN_and_Twitter_Posts.md:39 — The YouTube link https://youtu.be/yZzEBb-wK58 is referenced as an alternative to the hero GIF. Is this video public and owned by the org? If it's an unlisted/private draft, it needs to be made public before the thread goes out.
• server/app/heron/src/main.rs:374 — Is the intent for the eBPF advisory to fire on every Linux run without an eBPF source, or only when the user might benefit from the nudge (e.g. when they're capturing live traffic and eBPF would add value)? If the latter, the current unconditional fire is broader than intended.

Verified

• No sensitive-information leakage. Grepped the diff for RFC1918/CGNAT IPs, private-key material, internal hostnames, and machine-specific paths — none present. The /home/v/... → /home/user/... scrub in server/h-capture/src/ebpf/source.rs:910,921,925 matches the approved placeholder pattern used by scripts/lint/test-check-leakage.sh and docs/configure.md:133.
• Schema/storage untouched. No *-duckdb SQL changes; no body-scan smells; no arg_max/MAX(body) patterns introduced. The OTel rename (traces/spans) was already in Unreleased and is now correctly placed under [0.7.0].
• Capture pipeline unchanged. h-protocol/tcp.rs / joiner.rs not touched. The only h-capture change is the test-path scrub — exe_link_has_basename behavior is unchanged (the assertion is on the basename, prefix is irrelevant per the commit message).
• Rust type/fn compatibility. CaptureSourceConfig::Ebpf { .. } variant exists at server/h-common/src/config.rs:310 and is already imported in main.rs:17. The matches! pattern at main.rs:373 compiles against the real variant shape (verified struct fields). effective_pipelines is Vec<PipelineDef> with a .sources field (used identically at main.rs:316), so the flat_map(|def| def.sources.iter()) is sound.
• Console change is leaf-only. console/src/pages/settings.tsx:327–342 adds a static <span> badge and rewords two description strings — no new route, no new hook, no queryKey change, no TS↔Rust type mirror touched. No app.tsx registration needed.
• Version SSOT consistency. VERSION = 0.7.0, server/Cargo.toml workspace.package.version = 0.7.0, console/package.json version = 0.7.0, all workspace crates in Cargo.lock bumped to 0.7.0 (the lone 0.6.0 at Cargo.lock:819 is the third-party convert_case crate, not a workspace member).
• README asset references resolve. docs/images/hero.gif (70802 bytes, matches diff), docs/images/agent-turn-detail.png, docs/images/services-path.png all exist. install.sh exists at repo root. --exit-after-drain flag exists (main.rs:118,871). testdata/pcaps/ exists (though pcaps are in corpus/ subdir — see Suggestion).
• Commit message ↔ diff alignment. All four commit claims verified: (1) eBPF test path scrub ✓, (2) README rebuild + launch collateral + 0.7.0 bump ✓, (3) eBPF advisory in main.rs + Settings UI tag ✓, (4) Cargo.lock sync ✓.

---

🤖 Reviewed by the review bot • workflow run