@tikoci/centrs
    Preparing search index...

    Interface ExplainSubcommandFacts

    A […] command substitution, re-constituted against its enclosing menu.

    Same vocabulary as ExplainStatement, deliberately: an inner command is a command, and a caller should not have to learn a second shape to read one.

    That means the verb boundary here is Q6's answer (resolveVerb over the bracket's inner text), not Q3's Resolution.path. The two are not always the same — Q3's path is documented as the greedy leading run, its "best guess", and it reads [/system/identity/get name] as the menu /system/identity/get where Q6 reads menu /system/identity + verb get. Q6 is the module that decides verbs (and #211's R9 exists precisely so these two stop contradicting each other), so it is what the envelope presents; Q3's alternative readings survive as candidates. Where Q3 REFUSED, this refuses too, whatever Q6 says — the fail-closed floor is not up for a second opinion.

    interface ExplainSubcommandFacts {
        candidates: string[];
        context: string;
        contextCertain: boolean;
        depth: number;
        ev: string;
        span: ExplainSpanRange;
    }

    Hierarchy (View Summary)

    Index

    Properties

    candidates: string[]

    Every path the inner command could resolve to, shortest first.

    context: string

    Menu context in force at the bracket, / at document root.

    contextCertain: boolean

    Was the menu context in force BEFORE this statement known? A false here does not invalidate a resolved reading — the resolver already degrades every context-DEPENDENT statement when context is lost, so a statement that still resolved did not consume it (#192, #197).

    depth: number

    Bracket nesting depth; 0 is directly inside a statement.

    ev: string