Restructure into a cargo workspace and refresh GitHub Actions

[senamakel]

What changed and why

The crate was a single root package that mixed the wire contract with the
implementation. A host that loads the cdylib cannot use anything out of it,
so it had no way to name the payload types without compiling the whole module —
tinybus, tokio and the module SDK included.

This splits the repository into a virtual cargo workspace under crates/:

• crates/template-bus — the wire contract. The interface name, object
  path, and one constant per member (names); the Greet request/response
  payloads (greeting); and CONTRACT_VERSION plus the host bind rule
  (version). Two pure-Rust dependencies, serde and serde_json. No
  transport, no runtime, no behavior.
• crates/template — the implementation: the greet behavior, the
  crate-wide error type, and the TinyBus adapter, built as both an rlib and
  the cdylib the loader consumes. It depends on template-bus and re-exports
  all of it, so template::GreetRequest and template_bus::GreetRequest are
  the same type rather than structural twins.

Shared metadata, dependencies, and the whole lint set now live once in the root
[workspace.package] / [workspace.dependencies] / [workspace.lints], and
members inherit them.

GitHub Actions move to their latest major versions: actions/checkout@v7,
actions/upload-artifact@v7 (from v4), actions/download-artifact@v8 (from
v4), taiki-e/install-action@v2 with an explicit tool:, and
submodules: recursive everywhere.

Public API and behavior changes

Yes — breaking, and deliberate for a template:

• The package is renamed rust-template → template, so the library is
  libtemplate.{so,dylib,dll} and release assets are
  template-<version>-<platform>.<tar.gz|zip>.
• The bus interface is renamed ai.tinyhumans.rust_template.Greeting →
  ai.tinyhumans.template.Greeting, and the object path with it.
• Greet now takes a GreetRequest and returns a GreetResponse instead of a
  bare string on each side. That is the point of the contract crate: a host
  names the payload from a library instead of by string literal.
• New crate template-bus on the public surface, re-exported from template.

CI and release

• check-file-coverage.sh scans crates/ and runs cargo llvm-cov --workspace.
• New CI step asserts template-bus never pulls in a transport, an async
  runtime, an HTTP client, or a native library — the forward cargo tree -p
  form, because the inverse form silently discards the -p scope.
• New CI step runs the bundled example; --all-targets only compiles one.
• deny.toml sets allow-wildcard-paths = true. Workspace-internal path
  dependencies deliberately carry no version: it would be a caret range, so
  the first bump past 0.1.x would stop resolving and the release workflow
  would discover it after the tag was pushed. The exemption is narrow — it
  applies only to path deps on crates with publish = false, and a wildcard on
  anything from a registry is still denied.
• The release workflow selects its package by name (RELEASE_PACKAGE: template)
  rather than packages[0], whose order cargo does not promise, bumps the
  single [workspace.package] version, and verifies the bump took before
  tagging.

Validation

CI is green on this branch (run 32494741317): Rust, Docs, MSRV, Supply chain.

Locally:

Command	Result
cargo fmt --all -- --check	pass
cargo clippy --all-targets --all-features -- -D warnings	pass
cargo build --all-targets --all-features	pass
cargo test --all-features	pass — 32 tests across both crates
RUSTDOCFLAGS="-D warnings" cargo doc --no-deps --all-features	pass
cargo deny check all	pass
.github/scripts/check-file-coverage.sh 90 coverage.json	pass — every file ≥ 93%
cargo build --locked --release --lib -p template	pass
cargo run -p template --example verify_module -- target/release/libtemplate.so	pass — loaded through the real dynamic loader and answered Greet

Notes

• crates/template is an ordinary workspace member, not its own workspace root.
  The [workspace.package] inheritance failure that forces a separate root in
  other repositories does not reproduce here; it was checked rather than assumed.
• Docs updated in the same change: README.md, AGENTS.md (and so CLAUDE.md),
  MODULE.md, docs/specs/, docs/plans/, and a new
  crates/template-bus/README.md explaining why the contract is its own crate.
• No deliberately untested edge cases.

Summary by CodeRabbit

• New Features

  • Reorganized the project into a workspace with separate contract and implementation packages.
  • Added typed greeting requests and responses, shared service naming, and contract version compatibility checks.
  • Added a TinyBus greeting service with improved typed calls and validation.
  • Added consistent error handling for empty names.

• Documentation

  • Updated setup, API, module, and release documentation for the new package structure and naming.

• Tests

  • Expanded coverage for serialization, compatibility, greeting behavior, service contracts, and release verification.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6f8b7109-b82f-418b-92d7-235af49987ac

📥 Commits

Reviewing files that changed from the base of the PR and between a31ff1b and 3dc4594.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (39)

• .claude/settings.json
• .github/scripts/check-file-coverage.sh
• .github/workflows/ci.yml
• .github/workflows/release.yml
• AGENTS.md
• Cargo.toml
• MODULE.md
• README.md
• crates/template-bus/Cargo.toml
• crates/template-bus/README.md
• crates/template-bus/src/greeting/mod.rs
• crates/template-bus/src/greeting/test.rs
• crates/template-bus/src/greeting/types.rs
• crates/template-bus/src/lib.rs
• crates/template-bus/src/names/mod.rs
• crates/template-bus/src/names/test.rs
• crates/template-bus/src/version/mod.rs
• crates/template-bus/src/version/test.rs
• crates/template/Cargo.toml
• crates/template/examples/basic.rs
• crates/template/examples/verify_github_release.rs
• crates/template/examples/verify_module.rs
• crates/template/src/error/mod.rs
• crates/template/src/error/test.rs
• crates/template/src/greeting/mod.rs
• crates/template/src/greeting/test.rs
• crates/template/src/lib.rs
• crates/template/src/tinybus_module/README.md
• crates/template/src/tinybus_module/mod.rs
• crates/template/src/tinybus_module/test.rs
• crates/template/tests/public_api.rs
• deny.toml
• docs/plans/example-retry-policy.md
• docs/plans/tinybus-module-release.md
• docs/specs/example-retry-policy.md
• docs/specs/tinybus-module-release.md
• src/lib.rs
• src/tinybus_module/README.md
• src/tinybus_module/mod.rs

---

📝 Walkthrough

Walkthrough

The project becomes a Cargo workspace with separate template-bus and template crates. The contract crate defines typed greeting payloads, names, and version checks. The module crate implements the TinyBus adapter. CI, release workflows, documentation, and examples now target the workspace.

Changes

Workspace split and typed TinyBus contract

Layer / File(s)	Summary
Workspace configuration and package layout Cargo.toml, crates/*/Cargo.toml, AGENTS.md, README.md, deny.toml	The root manifest now defines shared workspace metadata, dependencies, lints, and members. The documentation describes the separate contract and implementation crates.
Typed bus contract crates/template-bus/src/*, crates/template-bus/README.md	template-bus exports typed greeting payloads, interface names, method metadata, and contract-version compatibility checks. Tests validate JSON shapes, names, and version rules.
Template API and TinyBus adapter crates/template/src/*, crates/template/tests/*, crates/template/examples/*	template exposes greeting behavior and errors, implements the typed TinyBus service, and updates module verification to use generated contract values.
Workspace CI and release automation .github/workflows/*, .github/scripts/check-file-coverage.sh, MODULE.md, docs/*, .claude/settings.json	Automation now selects the workspace package, checks workspace coverage and contract dependencies, uses recursive submodules, and publishes template-named artifacts.

Estimated code review effort: 4 (Complex) | ~60 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Caller
  participant TinyBusModule as template TinyBus module
  participant Greeting as template::greet
  participant Contract as template-bus
  Caller->>TinyBusModule: Send typed GreetRequest
  TinyBusModule->>Contract: Decode contract payload
  TinyBusModule->>Greeting: Call greet(name)
  Greeting-->>TinyBusModule: Return greeting or Error
  TinyBusModule->>Contract: Encode GreetResponse
  TinyBusModule-->>Caller: Return typed response

Loading

Poem

I’m a rabbit with a workspace map,
Two crates now share the hop and path.
Typed greetings cross the TinyBus stream,
CI checks each contract seam.
Release wheels roll, names align—
A tidy burrow, build by design!

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

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.}

[tinysweeper]

tinysweeper found nothing blocking. Approving.

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

[tinysweeper]

taiki-e/install-action is pinned to v2, which is mutable

A tag or branch can be repointed by whoever owns taiki-e, and the new code runs with this workflow's secrets. Pin to a full commit SHA and let Dependabot bump it.

[RULE] unpinned-action ·

[tinysweeper]

taiki-e/install-action is pinned to v2, which is mutable

A tag or branch can be repointed by whoever owns taiki-e, and the new code runs with this workflow's secrets. Pin to a full commit SHA and let Dependabot bump it.

[RULE] unpinned-action ·

[tinysweeper]

How this change flows

0 changed behaviours across 2 relationships. 4 surrounding behaviours are shown (60 graph nodes walked). 56 further behaviours left out to keep the diagram readable.

flowchart LR
  n0["Error"]:::impacted
  n1["Result"]:::impacted
  n2["setup"]:::impacted
  n3["INTERFACE"]:::impacted
  n1 -->|uses| n0
  n2 -->|uses| n3
  classDef changed fill:#0d4429,stroke:#238636,color:#e6edf3
  classDef impacted fill:#161b22,stroke:#6e7681,color:#c9d1d9
  classDef flagged fill:#5a1e02,stroke:#d93f0b,color:#ffffff
  classDef blocking fill:#67060c,stroke:#f85149,color:#ffffff

Loading

_{Green: changed behaviour. Grey: surrounding behaviour. Arrows name the call, use, implementation, or test relationship. Orange: has findings. Red: has a finding that blocks the merge.}