fix(hosting): compile the hosting family into the product

[M3gA-Mind]

Summary

• Compiles the hosting family into the product. It is currently built in no configuration — 1,643 lines including a 511-line test file and nine hosting_* agent tools, shipped in nothing.
• Restores the gate's own declared intent ("Default-OFF, product-ON"); this is not a new product decision.

Problem

The gate exists in the root Cargo.toml and states what should happen:

# ... Default-OFF, product-ON: a host with no hosting credential has no use for the tools, and an agent that can deploy to the internet is authority a headless embedding should have to ask for.

But hosting is in [features] default — no; in scripts/ci/product-features.txt — no; in the shell's forwarding list — no. "product-ON" never happened.

Why the guard did not catch it. check-feature-forwarding.mjs asserts set equality between the core's default gates and the shell's forwarding list. hosting is absent from both, the sets agree, the gate passes. A gate cannot catch a feature nobody told it about.

This is the shape of #4901, where voice shipped missing to 56 users — the incident that guard was built to prevent.

It is also the concrete case behind #5613: because hosting is in no CI command, Rust Core Coverage on #5593 ran 0 tests; 12202 filtered out and reported success.

Solution

Add hosting to scripts/ci/product-features.txt and to the shell's forwarding list together — the forwarding gate requires both to move at once.

Everything else was already wired: src/openhuman/mod.rs:29 declares the module behind the gate and src/openhuman/tools/ops.rs:1031 registers the tools.

This does not expose anything to users who have not asked for it

Tool registration is credential-gated on Account::from_config, matching the gate's own comment that "a tool that cannot work is worse than a tool that is not there". A host without [hosting].api_key or the provider's environment variable sees no new tools. What changes is that the code is compiled, linted and tested.

app/src-tauri/Cargo.lock gains tinyhosts 0.1.5 — a required consequence, and CI builds --locked, so it ships with the change. Verified the lockfile diff is that one package and nothing else.

Submission Checklist

• Tests added or updated — N/A: build-configuration change. The family already carries a 511-line test.rs which this PR causes to be compiled and run for the first time. That is the substance of the change: no new test is needed, an existing suite starts executing.
• Diff coverage ≥ 80% — N/A: no executable lines changed. The diff is a feature-list entry, a forwarding-list entry and a lockfile.
• Coverage matrix updated — hosting newly reaches the product set. If the matrix tracks it as a feature row, it wants adding; I could not find an existing hosting row to update, so flagging for a reviewer rather than inventing one.
• All affected feature IDs listed under ## Related — N/A: no matrix feature IDs identified for hosting.
• No new external network dependencies introduced — none at build time. At runtime the tools call a hosting provider, but only once a credential resolves, which is pre-existing behaviour now actually reachable.
• Manual smoke checklist updated — flagged: this is the first build in which hosting_* tools can appear, so a smoke entry for "configure a hosting credential, confirm the tools register" is worth adding. Not added here — I would rather a maintainer own that wording.
• Linked issue closed via Closes #NNN — see ## Related.

Impact

• Build: the core and shell now compile openhuman::hosting and link tinyhosts. Expect a small build-time and binary-size increase.
• Runtime: none for users without a hosting credential.
• Risk: the family has never been compiled by CI, so this PR is the first time its 1,643 lines face the compiler and its tests run. That is the point, but it means this PR's own CI result is the first real signal about that code. If it goes red, the failure is pre-existing rather than introduced here.

Related

• Closes: build: the hosting family is compiled in no configuration — not default, not product, not the shell #5614
• Refs ci: the Rust coverage gate reports success after running zero tests #5613 (the coverage gate that let it through), Add the hosting domain: deploy a workspace to a real hosting provider #5578 (added the domain), [Phase 2] feat(hosting): add rollback, deployment history and logs #5593 (added rollback/history/logs).

---

AI Authored PR Metadata (required for Codex/Linear PRs)

Linear Issue

• Key: N/A
• URL: N/A

Commit & Branch

• Branch: N/A
• Commit SHA: N/A

Validation Run

• pnpm --filter openhuman-app format:check — N/A: no formatted source changed.
• pnpm typecheck — N/A: no TypeScript changed.
• Focused tests: node scripts/ci/check-feature-forwarding.mjs → OK, 19 shell forwards, both lists moved together.
• Rust fmt/check (if changed): N/A: no Rust source changed — this enables existing Rust.
• Tauri fmt/check (if changed): N/A: app/src-tauri/Cargo.toml feature list + lockfile only.

Validation Blocked

• command: cargo check --features "$(bash scripts/ci/product-features.sh)" including hosting
• error: not blocked by tooling — declined on cost (a second ~25-35GB target/ for the product feature set)
• impact: the family's first compile happens in this PR's CI. Called out under Impact.

Behavior Changes

• Intended behavior change: openhuman::hosting is compiled into the product and the shell.
• User-visible effect: none without a hosting credential; with one, the nine hosting_* tools become available as originally intended.

Parity Contract

• Legacy behavior preserved: the gate remains default-OFF, so headless embedders opt in explicitly.
• Guard/fallback/dispatch parity checks: check-feature-forwarding.mjs passes with both lists updated.

Duplicate / Superseded PR Handling

• Duplicate PR(s): none
• Canonical PR: this one
• Resolution: N/A

Summary by CodeRabbit

• New Features
  • Enabled hosting capabilities in the desktop application.
  • Added tools for managing hosted sites, databases, environments, domains, and deployments.
  • Hosting tools remain available only when the required credentials are configured.
  • Added support for managing hosting workflows from the application, including deployment-related operations and workspace hosting setup.

[tinysweeper]

tinysweeper found nothing blocking. Approving.

$0.0000 · 0 in / 0 out · 111 embedded · openrouter/openai/text-embedding-3-small

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: d8573bf2-90d5-4aa8-81c9-a3c4edac3212

📥 Commits

Reviewing files that changed from the base of the PR and between 5da7ad6 and 813ad80.

📒 Files selected for processing (1)

• .github/workflows/ci-lite.yml

Included review availability: Your plan provides up to 10 included reviews per hour; 4 remain after this review.

---

📝 Walkthrough

Walkthrough

The desktop application now forwards the hosting feature to openhuman_core. The product feature list includes the hosting gate. Rust CI runs when product feature definitions change.

Changes

Hosting feature enablement

Layer / File(s)	Summary
Forward and ship hosting feature app/src-tauri/Cargo.toml, scripts/ci/product-features.txt	The desktop application forwards the hosting feature to openhuman_core. The shipped product feature list documents the hosting_* tools and credential requirement.
Trigger CI for product feature changes .github/workflows/ci-lite.yml	The rust-core and rust-core-full path filters include product feature changes. These changes now trigger the corresponding Rust checks and coverage.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to 813ad

This change compiles the hosting family into the product and activates its CI coverage without exposing tools to users lacking credentials. No actionable merge-blocking risk remains beyond normal checks and review.

Possibly related PRs

• tinyhumansai/openhuman#5468: Established related product feature and CI integration.
• tinyhumansai/openhuman#5488: Updated product feature propagation and CI coverage.
• tinyhumansai/openhuman#5578: Introduced the hosting feature and its credential-gated tools.

Suggested labels: rust-core, bug, infra-ci-release

Suggested reviewers: senamakel, tinysweeper

Poem

A rabbit found the hosting gate,
And helped the build include its state.
CI now checks the feature trail,
Credentials guard each tool detail.
The product list no longer fails.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the primary change: enabling the hosting feature in product builds.
Linked Issues check	✅ Passed	The changes add hosting to product and shell feature forwarding and update CI filters, satisfying issue #5614 objectives.
Out of Scope Changes check	✅ Passed	The CI path-filter changes directly support validation of the product feature changes and are within the stated scope.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[M3gA-Mind]

Pushed 813ad805 — CI was going to skip the code this PR enables

While waiting on the first run I checked what its own Detect Changed Areas job resolved to. It was this:

Detected 3 changed files
Changes output set to ["rust-tauri"]

rust-core was false, so both clippy steps — gated if: needs.changes.outputs['rust-core'] == 'true' (ci-lite.yml:379, :391) — were skipped, and Rust Core Coverage never queued at all. On the one PR whose entire purpose is to make openhuman::hosting compile for the first time, none of it would have been compiled or linted. The Risk paragraph in the description ("this PR's own CI result is the first real signal about that code") was simply not true as things stood.

The cause is that scripts/ci/product-features.txt is in no path filter. The rust-core filter lists Cargo.toml, Cargo.lock, src/**, tests/** — but not the file that decides which gates those lanes compile with. All three Rust lanes read it through scripts/ci/product-features.sh: clippy's --features (ci-lite.yml:388), the test suite's (test-reusable.yml:190), and rust-coverage-changed.sh:43. So changing the product's feature set did not arm the lanes that build the product.

That is the same shape as #5613 — a lane reporting success because it was scoped to nothing.

The change: add scripts/ci/product-features.* to the rust-core and rust-core-full filters. It belongs in both for the same reason Cargo.toml is in both: a feature-set change alters what compiles, which invalidates per-module test scoping. The glob covers product-features.sh too, since the parser decides the same thing.

This is a deliberate step beyond the PR title and I would rather flag it than let the PR go green on a vacuous run. If you would prefer it split into its own PR, say so and I will lift it out — but then this one should not be read as evidence that the hosting family compiles.

Consequence for this run: because ci-lite.yml is itself the first entry in every filter, this push arms rust-core, so the clippy product lane, the contributor-default lane and Rust Core Coverage all execute against the hosting family. That is the signal the description promised, and it arrives for the first time on this run. If it comes back red, the defect is pre-existing in code that has never faced the compiler — I will fix it here rather than disable anything.

Nothing else changed: the three original files are untouched.

[M3gA-Mind]

Green — and the risk in the description is discharged, with evidence

All 21 checks pass on 813ad805, PR CI Gate included. The part worth reporting is not the checkmarks but what ran behind them, since the description said this PR's own CI would be the first real signal about code that had never been compiled.

The lanes ran, and in full-suite mode. rust-coverage-changed.sh reported:

FULL: true
[ci][rust-cov-changed] running FULL instrumented suite
  (reason: build-config/workflow-level change detected by paths-filter)

clippy genuinely linted the family:

cargo clippy -p openhuman --features channels,media,inference,voice,web3,documents,modules,
  flows,meet,skills,mcp,crash-reporting,http-server,scheduler-gate,file-logging,contacts,
  runtime-node,memory-git,hosting -- -D warnings
    Finished `dev` profile in 3m 48s

All three clippy steps executed — product set, contributor set, Tauri shell — none skipped. Zero findings. So mod.rs (195 lines) and tools.rs (937) compiled and linted clean on their first encounter with the compiler.

And the 511-line test.rs ran — 26 tests, all passing:

openhuman::hosting::test::a_path_outside_the_workspace_is_refused ... ok
openhuman::hosting::test::an_account_reports_itself_without_its_credential ... ok
openhuman::hosting::test::hosting_off_yields_no_account ... ok
openhuman::hosting::test::only_the_tools_that_change_the_world_carry_an_external_effect ... ok
openhuman::hosting::test::rolling_back_to_a_deployment_that_never_built_does_not_touch_production ... ok
… 21 more

Suite totals: 13,058 passed, 0 failed. Not the 0 tests; 12202 filtered out shape from #5613 — I checked specifically, because a green checkmark on that lane has been meaningless before.

So the claim in the description now has evidence behind it: the family is sound, and it had simply never been built.

One caveat I would rather state than let you infer. This run armed rust-core because 813ad805 edits ci-lite.yml, which is the first entry in every filter — not because of the product-features.* glob I added. The glob fixes the general case: the next PR that touches only scripts/ci/product-features.txt will arm these lanes, where before it would not have. That specific path is not exercised by this run and I have no way to exercise it here.

If you want that locked in, the natural home is a case in scripts/__tests__/ asserting that every input the Rust lanes read appears in the rust-core filter — the same shape as check-feature-forwarding.mjs. I have not added it: I have already stepped past this PR's title once and would rather you decide than widen it again unasked. Happy to add it here or open it separately.

Not requesting CodeRabbit re-approval — it re-reviewed 813ad805 and returned "No actionable comments were generated", zero inline comments.