Hi,
when I read your post, I instantly came up with the system that may not be the target of OPERATE like ;; foo.asd ;; https://gist.github.com/privet-kitty/84350b73d528533ac8e19e5bba6aa333 (defpackage :foo.asdf (:use :cl :asdf :uiop) (:export #:hideable-system)) (in-package :foo.asdf)
(eval-when (:compile-toplevel :load-toplevel :execute) (defclass hideable-system (system) ((private :initform nil :initarg :private :reader private-p)) (:documentation "If PRIVATE is true, ASDF signals an error when one tries to OPERATE this system."))
(defmethod operate :around (operation (component hideable-system) &key &allow-other-keys) (if (private-p component) (error "Private system ~S cannot be directly operated." (component-name component)) (call-next-method))))
(defsystem "foo" :license "public domain" :depends-on ("foo/private") :components ((:file "main")))
(defsystem "foo/private" :pathname "private" :class "FOO.ASDF:HIDEABLE-SYSTEM" :private t :components ((:file "package")))
Here FOO/PRIVATE cannot be OPERATEd (but can be PERFORMed and then loaded, compiled, tested etc. via FOO). It seems to work at least superficially, though ASDF Best Practices states:
You SHOULD NOT define methods on asdf:operate --- most of the time it's totally the wrong thing because users would not be "operating" on your system, but on their system that depends on it. Instead you SHOULD define methods on asdf:perform, asdf:component-depends-on, etc.
https://gitlab.common-lisp.net/asdf/asdf/blob/master/doc/best_practices.md
Anyway, I don't have a sufficient knowledge on ASDF's internal.