---
id: HF-AUDIT-3
title: "hyperforge child-activation schema routing: `synapse lforge hyperforge build` errors 'No schema in response'"
status: Complete
type: analysis
blocked_by: []
unlocks: []
severity: High
target_repo: hyperforge
---

## Problem

After HF-CLEAN landed (hyperforge `4dacf7c`, v4.1.2) and the running server was restarted with the fresh release binary (PID 18804 on port 44104), synapse navigation into any child activation under hyperforge fails:

```
$ synapse --port 44104 --no-cache lforge hyperforge build
Fetch error at hyperforge.build: Protocol error: No schema in response
```

Schema fetch for the root activation (`hyperforge`) succeeds. Schema fetch for the child `build` fails.

Reproduced for `hyperforge.build`; likely reproduces for `hyperforge.workspace`, `hyperforge.repo` as well (all three use the `#[plexus_macros::child]` accessor pattern introduced in HF-CLEAN).

Raw RPC probes:

```
$ echo '{"jsonrpc":"2.0","id":1,"method":"hyperforge.build.schema","params":{}}' | websocat -t ws://127.0.0.1:44104/
{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}}
```

So the wire-level method `hyperforge.build.schema` is not registered on the server. Synapse expects that method to exist when it navigates to a child activation — it needs the child's `PluginSchema` to render the tree.

## Likely root cause

`#[plexus_macros::activation]` auto-emits a `schema` method on the activation impl (returns `PluginSchema`). For HF-CLEAN's `HyperforgeHub`, `schema` is at `hyperforge.schema`. For the child `BuildHub`, the synthesized method should be at `BuildHub.schema()` — but routed via `hyperforge.build.schema` through `HyperforgeHub`'s `ChildRouter` impl.

Hypotheses (each worth verifying):

1. **ChildRouter doesn't forward `schema` method calls.** The router generated by `#[plexus_macros::child]` accessors may only route *user-tagged* `#[method]`s to the child, not the auto-synthesized `schema()` / `_info` / `hashes` / `_protocol` introspection methods.
2. **BuildHub doesn't have `#[plexus_macros::activation]`** (maybe it's a plain struct with `#[plexus_macros::method]` blocks but no activation-level macro). If so, there's no `schema` method synthesized on it at all.
3. **ChildRouter routes the call but `BuildHub.schema()` returns `None`/empty** because `BuildHub` carries no state of its own (per the doc comment at `hubs/build/mod.rs` line near `fn build`).

## Investigation steps

1. `cd /Users/shmendez/dev/controlflow/hypermemetic/hyperforge/ && grep -n '#\[plexus_macros::activation' src/hubs/*.rs src/hubs/*/*.rs` — verify each hub has the activation attr.
2. Inspect plexus-macros' `#[child]` codegen: does the generated `ChildRouter` forward `schema` (the synthesized introspection method) or only the user's `#[method]`s?
3. Try `synapse lforge hyperforge workspace` and `synapse lforge hyperforge repo` — if all three fail identically, the bug is in ChildRouter codegen (not a BuildHub-specific quirk).
4. Read synapse's `Synapse.Schema.Transport` (or wherever schema fetches live) to see the exact RPC it sends for a child schema fetch — confirm the method name it expects.

## Proposed fix

Once root cause is identified, either:

- **plexus-macros fix**: `#[plexus_macros::child]` ChildRouter codegen forwards `schema`, `_info`, `hashes`, `_protocol` to the child activation (not just user methods). New plexus-macros patch version.
- **hyperforge fix**: each child hub (BuildHub, WorkspaceHub, RepoHub, etc.) gets an explicit `#[plexus_macros::activation]` or equivalent that guarantees the synthesized schema method exists and the parent's ChildRouter forwards to it.

## Risks

- This blocks any synapse-based introspection / invocation of hyperforge's child activations. Users see errors at the CLI.
- If the same bug exists in plexus-substrate (which also uses `#[child]` dynamic gates post-IR-18/19), it should be caught by IR-10 (synapse integration verification). Check: does `synapse lforge plexus-substrate claudecode session` work against current substrate? If yes, the bug is hyperforge-specific (different child pattern). If no, it's a broader macro issue.
- Workaround for HF-CLEAN validation: `cargo build --workspace` at hyperforge root does what `hyperforge.build.run --level 0` would do from the wire — verify compile gate independent of synapse navigation.

## Acceptance criteria

1. Root cause identified (one of the three hypotheses above, or something else).
2. Fix landed in plexus-macros and/or hyperforge.
3. `synapse lforge hyperforge build` renders the `BuildHub` schema tree.
4. `synapse lforge hyperforge build dirty path=... all_git=true` executes successfully and returns the dirty-repo stream.
5. Integration gate (rule 12): `cargo build --workspace` green in both plexus-macros and hyperforge.

## Completion

Ticket promoted when the user confirms scope. Implementer reports root cause + fix. Status flipped to Complete once `synapse lforge hyperforge build dirty ...` works end-to-end.

## Resolution (2026-04-20)

Fixed by **HF-AUDIT-4** (plexus-macros 0.5.2, commit `7eb06df` — see `plans/HF-AUDIT/HF-AUDIT-4.md`).

Root cause was **hypothesis 1** variant: the `#[plexus_macros::activation]` macro-generated `Activation::call` `_` arm contained a `.schema` strip-suffix shortcut that returned `SchemaResult::Method` for ANY method name matching the prefix, including `#[plexus_macros::child]` accessors (which since CHILD-8 / IR-10 appear in `plugin_schema.methods` with role `StaticChild` / `DynamicChild { .. }`). That short-circuited `route_to_child`, so the caller got the parent's child-accessor MethodSchema (content_type `*.method_schema`) instead of the child's PluginSchema (content_type `*.schema`) — and synapse's content-type filter rejected it as "No schema in response".

Narrow fix (HF-AUDIT-4): exclude child-role entries from the shortcut's `find` predicate. Regular `#[method]`s keep hitting the shortcut; child accessors fall through to `route_to_child`, which dispatches `"<child>.schema"` into the child activation and returns `SchemaResult::Plugin(<child_plugin_schema>)` as expected.

Verified end-to-end with hyperforge 4.1.3 (rebuilt against published plexus-macros 0.5.2 from crates.io):

- `synapse --port 44104 --no-cache lforge hyperforge build` renders BuildHub's schema tree (analyze, binstall_init, brew_formula, etc.).
- `synapse --port 44104 lforge hyperforge build dirty --path ... --all_git true` streams dirty-repo events correctly.
- `synapse --port 44104 --no-cache lforge hyperforge workspace` / `repo` drill-downs also render their schema trees.

Regression test pinned in `plexus-macros/tests/hf_audit_4_child_schema_drill_down_tests.rs`.
