feat(hosting): add hosting_deployment_logs

[CodeGhost21]

Adds hosting_deployment_logs, the tenth hosting_* tool and the last one outstanding for tinyhumansai/opencompany#913.

Why

hosting_deployment_status reports that a build failed and carries the provider's one-line error. Nothing returned the build output, so an agent that shipped a broken deploy could report the failure but not diagnose it — roll back blind, or hand it to a human. This is the read that makes a failed deploy actionable.

What

• DeploymentLogsTool over Host::deployment_logs, registered next to the other deployment reads.
• Read-only, no external effect. Takes the same deployment_id as hosting_deployment_status.
• Optional limit (default 100, clamped 1–1000). A build can record thousands of lines, which is a context window rather than a bill. The trim keeps the tail — the failure that sent an agent here is at the end, so dropping the head loses setup noise rather than the error.
• Three tests: the error survives to the model with each message bound to its stream; a limited read keeps the end; a missing argument is refused before any provider call.
• Tool tables in README.md and the two module docs updated nine → ten.

Do not merge yet — the pin is temporary

Host::deployment_logs is on tinyhumansai/tinyhosts#4, which has not merged. The first commit here pins vendor/tinyhosts at that PR's head (c0ff407) purely so this branch compiles and can be reviewed.

Before this merges: re-pin vendor/tinyhosts to the merge commit on tinyhosts main. I'll push that as soon as #4 lands.

For anyone looking at #4's red Rust check: it fails on a lint inherited from tinyhosts main that tinyhosts#7 already fixed there. Its last CI run predates that fix, and a re-run replays the same stale merge ref — it needs a close+reopen or a rebase, not a code change. Full detail on that PR.

Verification

Run locally against the pinned tinyhosts:

Lane	Result
cargo fmt -- --check	pass
cargo clippy -p openhuman --features "$(bash scripts/ci/product-features.sh)" -- -D warnings	pass
cargo clippy -p openhuman -- -D warnings (contributor set)	pass
cargo build --features hosting	pass
cargo test --features hosting hosting::	29 passed, 0 failed

hosting is in scripts/ci/product-features.txt, so the product clippy lane does cover this code.

After this

opencompany bumps its vendor/openhuman pin, declares the tool and gives it a consequence row — its hosting_ prefix defeats READ_ONLY_PREFIXES, so an undeclared hosting read parks rather than running. That's the last step before opencompany#913 closes.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

Warning

Your free Security trial is over. An organization admin can upgrade to Advanced for continuous pull request security review or dismiss this notice.

---

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

[M3gA-Mind]

Maintainer housekeeping — I rebased this branch onto current main (it was conflicting) and force-pushed. Both commits keep you as author; only the SHAs changed (75065f5 → 056379c). Please git fetch and reset your local branch before pushing again.

What conflicted, and how I resolved it

1. src/openhuman/hosting/tools.rs — the file was split under you. #5856/#5857 split large sources into _part_NN.rs fragments stitched back with include!(). tools.rs is now a 21-line header plus two include!s, so your diff no longer applied.

Resolution: kept main's stub and moved your additions verbatim into tools_part_01.rs — the DeploymentLogsTool registration stays after ListDeploymentsTool, and the tool itself stays immediately before the hosting_rollback banner, exactly where you put them. The Nine tools → Ten tools module-doc edit stayed in tools.rs, which still owns the header. No behaviour change: same diffstat as your commit (196 insertions, 4 deletions).

test.rs was renamed to hosting_tests.rs in the same wave; git followed the rename and your three tests applied cleanly.

2. vendor/tinyhosts — submodule conflict. main moved to 5caf686 (v0.1.6); your pin commit sets c0ff407. I re-asserted your pin rather than guessing, since that commit exists precisely to make the branch compile against tinyhosts#4.

Verified locally after the rebase

Lane	Result
cargo check -p openhuman --features hosting --lib --tests	0 errors
cargo test -p openhuman --features hosting --lib hosting::	29 passed, 0 failed
cargo fmt -- --check	clean
cargo clippy -p openhuman --features "$(bash scripts/ci/product-features.sh)" --no-deps -- -D warnings	clean

Same numbers you reported, so the relocation into the fragment is faithful.

One thing to fix before this can merge — the pin is a downgrade, not just temporary

Your note says to re-pin at the tinyhosts main merge commit once #4 lands. Worth flagging that the pin is a bigger problem than "temporary" implies today:

$ git merge-base --is-ancestor 5caf686 c0ff407   # v0.1.6 ⊆ your pin?
NO

c0ff407 is behind tinyhosts main — and so is #4's current head 2c35295, whose 3b04c8e merged an older main. Pinning either one walks vendor/tinyhosts backwards past v0.1.6 for the whole build, dropping:

• 5caf686 Release v0.1.6
• 6fe057a deps: bump base64 0.22.1 → 0.23.1
• db47201 deps: bump sha1 0.10.7 → 0.11.0

No API is lost (I checked — that is why it still compiles), but two dependency bumps get reverted repo-wide. Merging current main into tinyhosts#4 before it lands makes the eventual merge commit a true superset and the re-pin a clean forward move. Otherwise whoever does the re-pin has to notice this.

Also: deployment_logs is confirmed present at both c0ff407 and 2c35295 (src/host/mod.rs:143) and absent from tinyhosts main, so the dependency itself is exactly as you described.

Leaving this as a draft — it is correctly blocked on tinyhosts#4, which is still open. Not approving; a maintainer reviews and merges.

[M3gA-Mind]

CI came back after the rebase. Two new red checks, both the same root cause — the vendor/tinyhosts pin being behind main — and neither is a code problem. Reporting them since my rebase is what exposed them.

1. Module Pin Gate — fail. This gate did not exist when you opened this PR; it landed on main in #5812 (fix/5727-module-pin-drift-gate), so the rebase brought the branch under it for the first time. It reached the same conclusion I did, independently:

✗ vendor/tinyhosts moved SIDEWAYS — the new pin and the base pin have diverged,
  and 9 commit(s) on the base side are not reachable from it.
  The new pin is an ancestor of the one on the base branch...
  If the rewind is deliberate, say so: put [pin-rewind] in the PR title

There is an escape hatch, but I would not reach for it — merging current tinyhosts main into tinyhosts#4 fixes the cause rather than annotating it, and you need that merge before the final re-pin anyway.

2. Rust Quality (fmt, clippy) — fail, and it never reaches fmt or clippy:

error: cannot update the lock file /__w/openhuman/openhuman/Cargo.lock
       because --locked was passed to prevent this

Same cause. The rebase brought main's Cargo.lock, which resolves tinyhosts at v0.1.6 (with base64 0.23.1 / sha1 0.11.0); the submodule pin is older, so the lock no longer matches the tree and CI's --locked refuses to fix it.

Worth flagging why neither of us caught this locally: the verification lanes in your PR description, and the ones I ran after the rebase, do not pass --locked. Cargo silently rewrites Cargo.lock in the working tree and everything goes green. My run did exactly that — Cargo.lock came back modified locally, and I did not push it, because committing a lock rewrite driven by a backwards submodule pin would bury the problem rather than surface it. Adding --locked to a local check reproduces the CI failure in seconds.

Net effect of the rebase: CONFLICTING → MERGEABLE, and the two failures above, both pre-existing properties of the pin that current main now checks for. Nothing about hosting_deployment_logs itself is implicated — cargo check --features hosting --lib --tests is clean, all 29 hosting tests pass, and clippy on the product feature set is clean.

Once tinyhosts#4 merges current main and lands, re-pinning to the merge commit should clear all three at once: the gate, the lock, and your own note about the temporary pin. Still a draft, still correctly blocked on #4.

[M3gA-Mind]

Maintainer pass — I rebased this branch onto current main. New head 3e42bdc0d (was 056379cf2). Not an approval, and I have not merged anything.

Why

The branch was 44 commits behind main and 2 ahead. At that distance a green lane stops meaning much: the checks were reporting on a tree nobody will ever merge. It is now 0 behind, 2 ahead, so CI is finally answering about the code as it would actually land.

How, and what I did not do

Done with gh pr update-branch 5833 --rebase, i.e. GitHub replayed it server-side. No force-push from a local clone was involved at any point — that matters given what a shared-clone push did to #5719 earlier today.

Your two commits are intact and still yours:

	before	after
feat(hosting): add hosting_deployment_logs	056379cf2	3e42bdc0d
chore(hosting): pin vendor/tinyhosts at tinyhosts#4 for review	c0773099d	6ebf5d549

Author on both is still Ghost Scripter <ghostscripter@zerolend.xyz>, and the messages are untouched. I checked the content rather than assuming: the git patch-id of each commit is unchanged (c85b8e4fb…, aff07fcec…), and the SHA-256 of the full branch diff against its base is byte-identical before and after (631e1ee69b89…). vendor/tinyhosts still points at c0ff4075d. Nothing was rewritten — the work was only moved.

One side effect worth knowing: GitHub's server-side rebase drops commit signatures. Both commits were signed before and are unsigned now. main has no required_signatures protection and no CI gate checks it, so nothing is blocked — but if you want them signed, a local git rebase --exec 'git commit --amend --no-edit -S' and a --force-with-lease from your own clone will restore that.

CI: same three failures as before the rebase — I introduced none

Pre-rebase run 33570461758 failed on Module Pin Gate, Rust Quality, PR CI Gate. Post-rebase run 33579276439 fails on exactly the same three. The rebase changed the staleness, not the verdict.

They are not all yours, though, so it's worth separating them.

Yours — one root cause, two symptoms

vendor/tinyhosts is pinned to c0ff4075d, which is v0.1.5 (2026-08-23). main is at 5caf686f0, v0.1.6 (2026-08-30, Release v0.1.6). The new pin is an ancestor of the base pin, so this is a rewind, not a bump.

1. Module Pin Gate says so directly: "moved SIDEWAYS — 9 commit(s) on the base side are not reachable". Merging as-is would silently drop nine tinyhosts commits. The gate's message cites two occasions this already happened (Route the recall, reset and flush paths through the contract #5725 dropping eight tinyagents commits, and 14a23b9) — a gitlink rewind is two lines and no visible diff, which is exactly why it has its own gate.
2. Rust Quality → "Enforce Linux TLS dependency policy" was the pre-rebase failure, and it is the same thing wearing a different hat: Cargo.lock pins tinyhosts 0.1.6, the submodule now resolves to 0.1.5, so any --locked cargo invocation dies with "cannot update the lock file … because --locked was passed".

Both clear the moment the pin moves forward to something at or after 5caf686f0 — presumably once tinyhosts#4 is merged and released. If the rewind is deliberate for review, the gate accepts [pin-rewind] in the PR title or a comment, which would at least turn it into a conscious choice rather than a red check.

Not yours, and not mine — main is currently red

Post-rebase, Rust Quality no longer reaches the TLS step. It now fails one step earlier, at "Enforce OpenHuman Rust file layout":

src/openhuman/tools/impl/filesystem/git_operations.rs:       949 lines (limit 750)
src/openhuman/tools/impl/filesystem/git_operations_tests.rs: 929 lines (limit 750)

Neither file is in this PR. They arrived from main — #5672 merged them about ten minutes before I rebased, and main's own CI is red on this same job at 61d25fe21. Every PR rebased onto main right now will inherit it. I have flagged it separately; nothing for you to do here.

Note that this masks rather than resolves your TLS/lockfile failure — step 7 is now skipped, so it will reappear once main is healthy. Your Check Rust formatting step passed, for what it's worth.

Also

This is still a draft, so I have left it that way. Between that and the review-only tinyhosts pin, I read this as deliberately not ready yet — the rebase is just so the lane tells you the truth in the meantime.