feat: tag artifacts with a semantic kind at registration - #564
Draft
filip131311 wants to merge 1 commit into
Draft
feat: tag artifacts with a semantic kind at registration#564filip131311 wants to merge 1 commit into
filip131311 wants to merge 1 commit into
Conversation
Adds a closed ArtifactKind union to the artifact wire contract and requires
every producer to declare it when registering: ArtifactStore.register now
takes a single { hostPath, kind, ... } options object. MIME type tells a
consumer how to read the bytes; kind tells it what the artifact represents
(a screenshot vs. the annotated diff of two screenshots, a raw trace vs.
the report derived from it). The kind travels on the handle, the store
entry, and the /artifacts inventory items.
All current producers are tagged: screenshot (all four capture paths),
screenshot-diff, flow snapshot baselines/diffs, screen recordings, and the
native and React profiler exports and reports.
The native-profiler export keys are now typed at their source
(IosExportKey / AndroidExportKey) and mapped through a kind table that is
total over both unions, so a newly added export key fails to compile until
it is classified — nothing silently defaults.
The client-side mirror in tools-client keeps kind optional and widened
(ArtifactKind | (string & {})): an older tool-server sends no kind and a
newer one may send kinds this client predates, so consumers must treat it
as advisory metadata, never a hard contract.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fresh, from-current-main take on the artifact-kind idea from #398 / #466. Knowing what an artifact represents (not just its MIME type) is what a UI needs to group and name artifacts (e.g. in EAS); this PR delivers exactly that — the tagged handle — without the declared-output-map machinery.
Summary
ArtifactKindunion to the artifact wire contract;kindis carried onArtifactHandle,ArtifactEntry, and the/artifactsinventory items.ArtifactStore.registernow takes a single{ hostPath, kind, ... }options object, so the compiler forces every producer — current and future — to declare what it is emitting.screenshot/screenshot-diff-context), screen recordings (newscreen-recordingkind), and the native/React profiler exports and reports.IosExportKeyfrom theEXPORTStable,AndroidExportKey) and maps them through a kind table that is total over both unions — a newly added export key fails to compile until classified, replacing the previous stringly-keyed loop (and the?? "native-profile-trace"silent-default this design would otherwise need).@argent/tools-client), the mirrored handle type keepskindoptional and widened (ArtifactKind | (string & {})): an older, already-running tool-server sends no kind, and a newer server may send kinds this client build predates. Consumers treat it as advisory metadata; unknown kinds are opaque, never an error.Differences from #398 / #466 (deliberate)
@argent/artifactspackage, no thirdToolDefinitiongeneric, no per-tool output-name registrar, no runtime throw for “undeclared output” — the kind is plain data at the registration call site, checked at compile time where it can be, and a wrong label can never fail a tool at runtime. If a pre-invocationartifactsdeclaration in tool-listing metadata is ever needed (an actual EAS consumer), it can be layered on later without changing this wire contract.ArtifactKinddefinitions (registry / tools-client) stay deliberately separate — same as the existingARTIFACT_MARKERmust-match convention — because the client-side type is intentionally looser (optional + open) than the server-side one for version skew.Validation
npm run build(fulltsc --build)npm run typecheck:testsin registry, tools-client, tool-server, mcp, cli — cleanprettier --checkandeslint --max-warnings 0on all touched files🤖 Generated with Claude Code