Subcommands Hierarchy (De)Composition

[kudla]

Hi guys
My question is related to v3 still maybe there's some general idea for that across all the implementations.

Basically I' m interested is there any proper (intended by design) way for (co)composition across the subcommand hierarchy of

• managed dependencies
• execution flow it self

As it seems from the first glance any other endpoint command Action is almost kind of standalone function while cli framework is only just about to compose incoming configuration for it.
Still what about the dependance and logic sharing across the sibling commands.
I.e. instead of composition of repeatable code just in place of Actions their selves as follows (almost pseudocode )

app := &cli.Comnad{
 Name: "app",
 Commands: {
      Command{
          Name: "general-command",
          Commands: {
                Command {
                    Name: "a",
                    Action (ctx, cmd) {
                        appResource := initAppLevelResource()
                        processGenerallCommandLogic(appResource, "Command-A")
                    }
                },
                Command {
                    Name: "b",
                    Action (ctx, cmd) {
                        appResource := initAppLevelResource()
                        processGenerallCommandLogic(appResource, "Command-B")
                    }
                },
          }
      }
 }
}

Is it possible to resolve such sharing/decomposition by means of cli framework it self.
E.g. something like

app := &cli.Comnad{
 Name: "app",
 Action(ctx, cmd) {
   // Init global dependencies for all the application
   // E.g. global application logger
   ctx = context.WithValue(ctx, "logger", NewLogger("app"))
 },
 Commands: {
      Command{
          Name: "general-command",
          Action(ctx, cmd) {
                // Init command specific resources
                // E.g. extend logger with command specific attributes
                ctx = context.WithValue(ctx, "logger", ctx.Value("logger").With("command-related", "value"))

                 // or init any service/connection specific for all nested subcommands 
                 ctx = context.WithValue(ctx, "service-dependency",  NewService())


                 // Next process some general logic based on specific endpoint subcommand results
                 specificSubCommandResults := cmd.Run(ctx, cmd)
                
                 // And handle general shared logic
                ctx.Value("logger").Debug("Any subcommand generally formatted result %v", specificSubCommandResults)
          }
          Commands: {
                Command {
                    Name: "a",
                    Action (ctx, cmd) {
                       ctx.Value("logger").Debug("starting A command")
                       sharedResource := ctx.Value("service-dependency")
                       return "Result-A "  + sharedResource  // command specific  logic / results goes here
                    }
                },
                Command {
                    Name: "b",
                    Action (ctx, cmd) {
                       ctx.Value("logger").Debug("starting B command")
                       sharedResource := ctx.Value("service-dependency")
                       return "Result-B" + sharedResource // command specific  logic / results goes here
                    }
                },
          }
      }
 }
}

Actually it is obviously not the solution, as Actions are ment to return errors only and their context is not that mutable. Still this is something closest came to a mind to describe the idea.

Anyway is it really possible to organize something similar by cli means it self by design? Or maybe are there any other well known best practice patterns / work arounds for that.

Thanks