[Feature] Plugin System Design

Description

Firstly, really like where weaver is going. Great stuff.

As mentioned in the project readme - weaver might support a WASM-based plugin system. I am personally not familiar with WASM, or what building a custom WASM plugin might look like - and I also selfishly don't want to learn it.

A more simple, and extensible solution might be proxying to subcommands, such as how Git does.

Solution thoughts

Any binary in the host path prefixed with weaver- would be executed when run as weaver ${subcommand} args

which weaver
which weaver-gogen # Theoretical program for generating go semconv sdk that would integrate with my custom otel sdk
# returns real paths

weaver gogen --arg1="value"

• Creating git subcommands
• GIT_EXEC_PATH

Reasons

I think this way, you wouldn't be dictating which technologies, frameworks and languages an organisation would have to use. The end result would be that so long as you had an executable or alias with the right name, the behaviour is then completely up to the third-party.

It would also be much simpler to implement and maintain than anything WASM related (probably).

Start with the README's key-features section and the linked Git subcommand guidance, then inspect Weaver's existing CLI command dispatch. Done should be a maintainer-approved design that specifies plugin discovery, invocation, argument handling, and compatibility boundaries.