Customer-readiness gate: v0.2.0 + v0.3.1 Rule-6 walkthroughs + L-07 live cross-host smoke #7

New issue

Open

opened 2026-05-03 16:28:27 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-03 16:28:27 +00:00

Owner

Why

hero_assistance is engineering-complete pre-customer as of session 34 (Phase 22 / v0.3.1). Twenty locked decisions; open limitations are all post-v1. Every v1 acceptance criterion in #1 has shipped or has an accepted closure path.

Before declaring "ready for first customer", three eyeballs-on validations remain:

What

1. v0.2.0 Rule-6 walkthrough

The v0.2.0 candidate has been code-shipped since session 31 (5.1 of vision §5; the README lists it as 🚧 candidate, tag pending Rule-6 walkthrough sign-off). Every prior walkthrough surfaced real bugs:

s23 (Phase 15-release / Phase 17): Bootstrap-not-loading in _app desktop + stuck-on-enroll dead-end. Fixed mid-session.
s30 (Phase 16b-fix): 4 desktop UX bugs (× clipped, deadlock, ticket Link escape, breadcrumb escape).
s31 (Phase 16b-release-fix): B5 empty-launch blank screen (head-inject CSS) + B2 N=1→0 deadlock attempted-and-reverted.
s32 (Phase 16b-fix-redux): B2 actually closed via auto-pick selected_tab .peek() fix.

Walk the seeded 2-project demo (bash scripts/phase13_demo.sh) through:

Empty-launch (subs unset) → blank-screen guard
2 subs → tab strip + per-tab identity + theme + project-config Modal
Add / remove subs (especially N=1→0) → no UI deadlock
Cross-project event isolation (post a comment on Mycelium, confirm Hero tab does NOT see it; vice versa)
Enrollment (Email → Token → Done → "View your tickets" link)
Ticket detail: composer + image-paste + drag-drop + breadcrumb + presence sidebar

Capture 5 fresh PNGs under tests/baselines/desktop-{empty,mycelium,detail,hero,hero-error}.png per tests/baselines/desktop-README.md.

If clean: tag v0.2.0 on development. CI auto-publishes the 3 deploy binaries.

2. v0.3.1 walkthrough — TCP `/events` route

Phase 22 / D-20 shipped the new /events GET route on _server's TCP listener with per-recipient server-side filtering as the load-bearing privacy invariant. Hermetic test coverage is in default CI (phase22_events_tcp_per_user_filter_excludes_non_recipient + _requires_x_hero_user_in_dev_mode + _self_recipient_receives_envelope); cross-host smoke is #[ignore]-gated. No human walkthrough yet.

Drive the new route via curl per docs/runbook.md §/events subscription:

curl -sN -H "X-Hero-User: alice@hero.collab" http://[::1]:7777/events | python3 ...

Confirm:

Stream stays open; no envelopes until presence/comment events fire.
Drive a presence.set_status_text for Alice via curl /rpc; envelope arrives in Alice's /events stream.
Drive the same for a different user; does NOT arrive in Alice's stream (privacy invariant).
401 on missing X-Hero-User.

3. L-07 live cross-host smoke (CAP_NET_ADMIN required)

Run the two #[ignore]-gated cross-host tests with a TUN-capable mycelium binary:

sudo setcap cap_net_admin+ep $(which mycelium)
cargo test --release -p hero_assistance_server --test integration -- --ignored phase12b
cargo test --release -p hero_assistance_server --test integration -- --ignored phase22_cross_host

This is the only end-to-end proof that 2 mycelium daemons + 2 _servers + cross-overlay TCP /rpc + cross-overlay TCP /events actually round-trip on a real peer link. Both have been hermetic-tested; neither has been live-tested in CI.

If any of these surfaces real bugs: file a fresh issue + fix in a follow-up session. If all clean: hero_assistance is customer-ready.

Out of scope

L-02 (web gateway for mycelium-blocked customers) — separate post-v1 workstream; ~1 session of work; precise issue files when first customer engagement requires it.
MCP tool surface (compile 91 OpenRPC methods to MCP per vision §2.5) — optional forward work; ~1 session.

Refs

Master tracking issue #1 (v1 plan) — kept open until first customer signs (M3).
D-20 (events-over-TCP transport) — decisions/D-20-events-over-tcp-transport.md.
L-07 (narrowed s34) — limitations/L-07-cross-host-test-requires-cap-net-admin.md.
Phase 22 manifest — sessions/34.yml.

## Why hero_assistance is **engineering-complete pre-customer** as of session 34 (Phase 22 / v0.3.1). Twenty locked decisions; open limitations are all post-v1. Every v1 acceptance criterion in #1 has shipped or has an accepted closure path. Before declaring "ready for first customer", three eyeballs-on validations remain: ## What ### 1. v0.2.0 Rule-6 walkthrough The v0.2.0 candidate has been code-shipped since session 31 (`5.1` of vision §5; the README lists it as 🚧 candidate, tag pending Rule-6 walkthrough sign-off). Every prior walkthrough surfaced real bugs: - s23 (Phase 15-release / Phase 17): Bootstrap-not-loading in `_app` desktop + stuck-on-enroll dead-end. Fixed mid-session. - s30 (Phase 16b-fix): 4 desktop UX bugs (× clipped, deadlock, ticket Link escape, breadcrumb escape). - s31 (Phase 16b-release-fix): B5 empty-launch blank screen (head-inject CSS) + B2 N=1→0 deadlock attempted-and-reverted. - s32 (Phase 16b-fix-redux): B2 actually closed via auto-pick `selected_tab` `.peek()` fix. Walk the seeded 2-project demo (`bash scripts/phase13_demo.sh`) through: - Empty-launch (subs unset) → blank-screen guard - 2 subs → tab strip + per-tab identity + theme + project-config Modal - Add / remove subs (especially N=1→0) → no UI deadlock - Cross-project event isolation (post a comment on Mycelium, confirm Hero tab does NOT see it; vice versa) - Enrollment (Email → Token → Done → "View your tickets" link) - Ticket detail: composer + image-paste + drag-drop + breadcrumb + presence sidebar Capture 5 fresh PNGs under `tests/baselines/desktop-{empty,mycelium,detail,hero,hero-error}.png` per `tests/baselines/desktop-README.md`. If clean: tag **v0.2.0** on `development`. CI auto-publishes the 3 deploy binaries. ### 2. v0.3.1 walkthrough — TCP `/events` route Phase 22 / D-20 shipped the new `/events` GET route on `_server`'s TCP listener with per-recipient server-side filtering as the load-bearing privacy invariant. **Hermetic test coverage is in default CI** (`phase22_events_tcp_per_user_filter_excludes_non_recipient` + `_requires_x_hero_user_in_dev_mode` + `_self_recipient_receives_envelope`); cross-host smoke is `#[ignore]`-gated. **No human walkthrough yet.** Drive the new route via curl per `docs/runbook.md` §`/events` subscription: ```bash curl -sN -H "X-Hero-User: alice@hero.collab" http://[::1]:7777/events | python3 ... ``` Confirm: - Stream stays open; no envelopes until presence/comment events fire. - Drive a `presence.set_status_text` for Alice via curl `/rpc`; envelope arrives in Alice's `/events` stream. - Drive the same for a different user; does NOT arrive in Alice's stream (privacy invariant). - 401 on missing `X-Hero-User`. ### 3. L-07 live cross-host smoke (CAP_NET_ADMIN required) Run the two `#[ignore]`-gated cross-host tests with a TUN-capable mycelium binary: ```bash sudo setcap cap_net_admin+ep $(which mycelium) cargo test --release -p hero_assistance_server --test integration -- --ignored phase12b cargo test --release -p hero_assistance_server --test integration -- --ignored phase22_cross_host ``` This is the only end-to-end proof that 2 mycelium daemons + 2 `_server`s + cross-overlay TCP `/rpc` + cross-overlay TCP `/events` actually round-trip on a real peer link. Both have been hermetic-tested; neither has been live-tested in CI. If any of these surfaces real bugs: file a fresh issue + fix in a follow-up session. If all clean: hero_assistance is **customer-ready**. ## Out of scope - L-02 (web gateway for mycelium-blocked customers) — separate post-v1 workstream; ~1 session of work; precise issue files when first customer engagement requires it. - MCP tool surface (compile 91 OpenRPC methods to MCP per vision §2.5) — optional forward work; ~1 session. ## Refs - Master tracking issue #1 (v1 plan) — kept open until first customer signs (M3). - D-20 (events-over-TCP transport) — `decisions/D-20-events-over-tcp-transport.md`. - L-07 (narrowed s34) — `limitations/L-07-cross-host-test-requires-cap-net-admin.md`. - Phase 22 manifest — `sessions/34.yml`.