fix: reconcile the docs with what trond actually does

[barbatos2011]

An audit of every tracked doc against the built binary, ahead of the first tag. Three of the gaps turned out to be the implementation being wrong rather than the prose.

Implementation

--config was a dead flag. Registered on the root command and advertised in --help as "Config file (default ~/.trond/config.yaml)", but the whole codebase referenced configFile exactly twice — the declaration and the registration:

$ trond --config /nonexistent/definitely-not-here.yaml version
trond version ...        # exit 0, silently ignored

There is no config-file feature, so the flag is removed rather than left advertising a setting trond does not have.

An unknown --output fell through to text. The writers switch on "json" and default to text, so -o yaml — which contracts/cli-contract.md listed as supported — returned a human table with exit 0 to a caller that asked for machine-readable output. An agent then parses a table as JSON. --output and --log-format are now validated up front:

$ trond list -o yaml
Error [VALIDATION_ERROR]: unknown --output "yaml": expected text or json    # exit 2

Covered by TestValidateFormat.

network --help printed upgrade twice. upgradeCmd was added both in network.go's init and in upgrade.go's, where it sits with the MarkFlagRequired calls that have to run alongside it. Dropped the former; add already self-registers the same way.

Exit code 5 was promised and never emitted. ExitPartialSuccess = 5 was defined and used by no command. A multi-node partial result actually exits 1 with error_code: "PARTIAL_SUCCESS" (cmd/network/destroy.go:188), so an agent branching on 5 waits for a code nothing sends. The constant is removed, 5 is left unassigned rather than reused, and AGENTS.md now tells agents to branch on error_code — including that re-running the whole command is usually wrong, because the nodes that succeeded are already in the requested state.

Docs

• README never mentioned recipe, schema, mcp, doctor, verify-config, shadow-fork. Not "described thinly" — zero occurrences each. They are the agent-facing half of the CLI, documented in AGENTS.md and never carried across. Two new sections cover them.
• README's global-flags table omitted --require-private and --version.
• The Intent Reference's top-level block omitted monitoring (a real schema key, shown only under Commands), and nodes[].jar was the one node field out of 29 with no README entry.
• CHANGELOG claimed 32 CLI commands; there are 40 top-level plus subcommands, and its group list omitted snapshots, builds, shadow-fork and the agent interfaces entirely. This ships as the v0.1.0 release notes.
• SECURITY.md still said 0.1.x (alpha) after docs(changelog): make the first release v0.1.0, and fold in the alpha section #223 settled on v0.1.0. Its private-key section could also be read as "keys never touch disk" — the key is inlined into the rendered HOCON at apply time, because that is where java-tron reads localwitness from. It says so now, and notes the audit log follows --state-dir.
• contracts/cli-contract.md advertised --config and -o yaml, both unimplemented, and omitted --state-dir and --require-private.

The published private-net key

private_net_config.conf carries a plaintext witness key (a31d54…acae, address TM4yToQ1njkcFwi3ADY5x6dbdfNekU3rVi). It stays — the genesis block in that same file is derived from the matching address, so the template cannot produce blocks without it, and knowledge/test-harness.md already told readers to use that exact key.

What was missing is that nothing, at any of the four places it appears, said it is published. The template, AGENTS.md and knowledge/test-harness.md now state plainly that the key is public, that any rig using it is unauthenticated (anyone reachable can sign as the witness and spend the genesis balance), and that it must never be reused on Mainnet, Nile, or any network carrying value.

No secrets found

The audit scanned every tracked file for token patterns, bare 64-hex, password/secret/api_key assignments, IPs, emails and internal ticket references.

• No API tokens, passwords, or SSH private keys.
• The only email is security@tron.network.
• The only public IPs are TRON's own mainnet snapshot mirrors, whose cleartext-HTTP posture knowledge/snapshots.md:103 already documents.
• The only bare 64-hex outside the key above is token-lab's compiled ERC20 bytecode.

Verification

check	result
make test	25/25 packages, 0 failures
every command appears in README	yes (was: 6 missing)
-o yaml / --log-format xml	exit 2
-o json	still exit 0
network --help upgrade rows	1 (was 2)
output.ExitPartialSuccess	no longer compiles
knowledge/ vs internal/knowledge/files/	byte-identical, 14 files

Go files touched: cmd/root.go, cmd/network/network.go, internal/output/exitcode.go, plus the new test. Local golangci-lint flags pre-existing SA5011s in internal/snapshot/snapshot_test.go and internal/apply/network_create_support_test.go — neither file is touched here; they surface because the local linter is built with Go 1.26.3 while CI pins the analysis toolchain to go1.25.11.

Not in this PR

SECURITY.md publishes a response SLA (48h acknowledgment, 5 business days to assessment, 30 days to fix for critical issues). That is a commitment to whoever staffs security@tron.network for this repository — worth confirming it is real before the first release makes it visible.