v2.52.0

Changed

• BREAKING: vault test probes the substrate's own status node and answers { id, status } alone. It probed discovery, which the substrate never registers — only event-logger-nodes mounts one — so a spoke running the substrate without that plugin failed the test with server returned TM_ERROR for probe while being perfectly reachable under a perfectly good credential. Status_CI is mounted unconditionally by newspack_nodes_mount_substrate_cis() and its get verb gates at READ, the same role discovery get declared, so no spoke has to grant anything new. It arrived in substrate 0.19.0, which is the floor this verb now carries: a spoke below that release answers status with a TM_ERROR and fails vault test where an ELN-carrying spoke used to pass, so upgrade the spoke rather than reading the failure as a bad credential. The response field carrying registered_hooks, custom_events and lag is gone: nothing read it, and those two keys are event-logger-nodes' ruleset vocabulary, sanitized a second time here beside Discovery_Collector_Node::sanitized_names(), which owns that payload.
• BREAKING: the vault verbs take --user= and --password= where they took --auth_username= and --auth_password=. An operator now writes cmd vault update austinchronicle --user=newspack-nodes-hub --password=<app password>, and a script still passing the old spellings is REFUSED rather than ignored — add and update now refuse any option they do not read, naming it and listing the ones they take. Nothing validates a verb's args declaration, so an unrecognized --key=value was simply an option the handler never looked up: silent in opposite directions, since add stored an empty credential and answered with the id it had registered, while update read the absence as "leave it alone" and answered a save that changed nothing. A stale spelling, a typo (--pasword=) and an invented flag are one bug, and the refusal runs ahead of any lookup or write. Only the two OPTION names moved: the stored keys, the list/get public shape and the auth_username / auth_password node arguments on HTTP_Out, Remote_Link, Remote_Source and SSE_In are unchanged, so every stored credential and every topology stands. The Vault admin tab sends the new spellings. A valueless option is refused with them. A bare --key parses as boolean true and (string) true is '1', so cmd vault update spoke --password — the value eaten by a shell, or simply forgotten — stored the literal 1 as the credential, announced the change and answered success, leaving that spoke answering 401 with nothing in the vault to say why. Every option these two verbs read names a value, a stored field or the id an entry moves to, so the rule keys on the option's shape rather than on a list of which ones. add refuses an absent --url in its own words as well, where Vault::add()'s generic check URL format (must be HTTPS) named the wrong cause; url is declared as the OPTION the handler reads, because the one command grammar rides a required arg POSITIONALLY and the console duly wrote cmd vault add <id> <url>, which the handler saw as no url at all.

Fixed

• wp nodes cli printed two prompts after every command when readline was unavailable but stdout was a real terminal. Two prompt owners collided: TTY_Out_Node::write() redrew a prompt behind each newline-terminated reply, and TTY_In_Node::drain_once() then drew its own fallback prompt for the next read. The readline path had never doubled, because it retired the prompt as readline handed a line over. Both paths now retire it in ONE place, TTY_In_Node::emit_line(), which clears both flags before the sink runs — so the reply written inside that dispatch takes the plain write path and only the fallback prompt reaches the screen. The readline callback records its line and nothing else: drain_once() emits from the queue on the very next statement, with nothing writing to the terminal in between.