Migrate Core Code to Submodules

Migrate core code into a vendored submodule

OpenHuman is the host: composition, config, security policy, approvals, lifecycle, and adapters. Behavior that is not specific to OpenHuman belongs in the owning vendor/tiny* project (see "Submodule ownership" in CLAUDE.md). This skill drives one migration end to end: plan, move code + tests, ship the submodule release, re-pin the host.

Default to executing. Use plan mode only for step 1 (the split decision), and only when the boundary is genuinely ambiguous or the move is large. Work in a worktree (worktree <slug> from the repo root); never on main. Do not squash commits; the auto-commit hook checkpoints for you.

How TinyBus fits

TinyBus is the seam that makes this migration possible and shapes its design.

• A loadable module is a first-party cdylib speaking the TinyBus module ABI, downloaded from a pinned GitHub release and attached to an in-process broker as a bus peer. The core calls it through a typed contract, not a Rust import.
• Each module has a *-bus contract crate (names, methods, request/response types, contract version). It is synchronous and free of I/O and runtime deps. Never redeclare a contract type in OpenHuman; call members through the contract constants.
• Because the module is a separate binary in the same process, anything you move must be reachable from the host through the bus contract. So a migration is usually three pieces: (a) implementation in the module crate, (b) new/changed methods and types in the *-bus crate (bump its contract version), (c) a thin host adapter under crates/openhuman-core/src/modules/<name>.rs (or the domain that calls it) that forwards to the bus and keeps policy/config/creds.
• Data that cannot cross a boundary (task-local state, callbacks, secrets) is passed explicitly in the request, or served to the module as a host callback (see modules/memory_host.rs). Credentials never ride in tool arguments; they go through module init/reinit config.
• Module code must not depend on openhuman. Host callbacks are traits/bus services the module defines and the host implements.
• Not every submodule is a loadable module. Pure libraries (tinyagents, tinytools, tinychannels, tinyskills, tinyvoice, tinywallet, ...) are linked via Cargo; a move there needs no bus contract or digest re-pin, only a gitlink bump. Check the module's MODULE.md/README to know which kind it is.

Step 1: Plan (freedom to decide the split)

1. Identify the code to move and read its callers. Use Explore/Grep on crates/openhuman-core/src/<domain>/.

2. Classify every item as moves or stays:

   Moves to the submodule	Stays in OpenHuman
   Algorithms, parsers, protocol/wire types, engines, generic tools, provider clients with no product identity	Config schema and loading, SecurityPolicy/approvals/sandbox decisions, credential resolution (resolve_backend_credential), Outcome<T> controllers and RPC schemas, event-bus publishing, product identity/attribution headers, Redux/Tauri glue
   Tests that exercise only the moved logic	Cross-module tests, host-adapter tests, JSON-RPC E2E, anything needing the mock backend or CoreContext

3. Pick the destination using the ownership table in CLAUDE.md. Put the change in the repo that owns the behavior, not where it is easiest to land. Read the target's README.md, AGENTS.md, crate boundaries and *-bus crate first.

4. You may create new crates in the submodule workspace when the code has no good home (e.g. a new tinyfoo-<thing> library crate, or a new *-bus if a new module needs its own contract). Prefer extending an existing crate. Only propose a brand-new submodule/repo when no existing project owns the concept; that one is a user decision, so stop and ask.

5. Write the plan down briefly (in the PR description or docs/plans/): what moves, what stays, new crates, bus contract changes, dependency direction, and the release order. Skip a formal doc for a small, obvious move.

Dependency rules to check while planning: the core must not depend on tinyhumans-sdk (only openhuman-tinyhumans may); a module must not depend on openhuman; there is one tinytools copy (via vendor/tinyagents/); tool-call parsing/dialects/agent loop belong in tinyagents, not the host.

Step 2: Move the code, upstream first

Submodule PRs go first, raised against that repo's canonical upstream (tinyhumansai/<name>), never a fork. Follow the submodule's own AGENTS.md/ CONTRIBUTING.md (fmt, clippy -D warnings, per-file coverage gates such as 90% in tinysearch's release workflow).

1. Branch inside the submodule at the recorded gitlink (the worktree helper already put every submodule on branch <slug>). Do not create nested worktrees.
2. Move the implementation into the target crate with git mv-style history where practical. Keep public API minimal and documented; keep files under about 500 lines.
3. Move tests with the code. Unit tests go beside the moved modules in the submodule. Add bus-contract tests in the *-bus crate for any new wire type. Tests that need the host stay in OpenHuman.
4. If a bus contract changed, bump its version and update both sides in the same change set. Keep the contract synchronous and I/O-free.
5. Replace the removed core code with the thin host adapter. Delete the old implementation and its old tests, do not leave a copy. Keep Outcome<T> controllers and RPC namespace strings (wire contracts) unchanged.
6. Verify in the submodule: cargo fmt --all -- --check, cargo clippy --all-targets --all-features -- -D warnings, cargo test --all-features (plus the coverage gate if the repo has one).
7. Open the submodule PR ready for review, babysit to green, merge. Unshallow submodule clones before merging upstream if needed.

If the change spans nested submodules (tinyagents/vendor/tinytools, tinymemory/vendor/tinycortex, ...), release/merge the innermost first and bump gitlinks outward.