archetech / archon / 29533522642

90%

push

github

feat: author real input schemas for structured-object tools (#727) (#732)

* feat: author real input schemas for structured-object tools (#727)

Five tools declared a loose JsonObjectSchema (any JSON object at all) and
handed it to a keymaster method needing a specific shape, so the server
advertised "send me anything" and failed deeper in. They now declare the real
shape: StoredWallet, VerifiableCredential, PollConfig, DmailMessage.

The unvalidatedShape() markers from #728 are gone, and so is get_property's:
didDocumentData is `unknown` and often not an object, so it now guards with
isJsonObject instead of casting -- which also stops an index into a string or
array returning a nonsense "property".

The hazard here is the opposite of the outputSchema one. Zod STRIPS unknown
keys on input parse rather than rejecting them, so a plain object where the
source type declares `[key: string]: any` would silently delete data: a
restored wallet's custom metadata, or a credential's claims. Schemas
passthrough exactly where the type declares an extension point (WalletFile,
IDInfo, Seed, credentialSubject) and stay closed where it does not (PollConfig,
DmailMessage), so junk is dropped rather than stored.

Nothing is stricter than the keymaster method behind it, or the tool would
reject input the CLI and REST API accept: deadlines stay plain strings (not
.datetime()) because keymaster accepts anything new Date() parses, and `proof`
is left unmodelled because updateCredential deletes and re-signs it. Semantic
rules keymaster owns -- deadline in the future, recipient resolves to an agent
-- are not duplicated; only what a client can act on before calling is.

The sweep test's fixtures were never valid shapes (a poll config with a `title`
field), which nothing caught while the schemas accepted anything.

Cost: ~615 tokens on listTools. Verified through a real McpServer/Client that
the wallet union survives JSON Schema generation as anyOf, custom metadata
survives th... (continued)

2940 of 3486 branches covered (84.34%)

Branch coverage included in aggregate %.

15 of 15 new or added lines in 1 file covered. (100.0%)

6120 of 6544 relevant lines covered (93.52%)

837.1 hits per line