{"version":"2.1.274","anchor":"artifact-bootframe-requests-gain-a-distinct-probe-kind-an","canonical_anchor":"artifact-bootframe-requests-gain-a-distinct-probe-kind-an","heading":"Artifact requests gain explicit kind and watchBoot parameters","tier":"internal","area":"Artifacts","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274\/e\/artifact-bootframe-requests-gain-a-distinct-probe-kind-an","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274","markdown":"### Artifact requests gain explicit kind and watchBoot parameters\n\nArtifact boot and fetch requests now take explicit kind (default 'probe') and watchBoot parameters instead of implicit behavior\n\n**Unclear.** The finding doesn't describe any visible effect of this beyond the internal request format.\n\n**What**\n\n- The artifact frame-boot request function now takes a `kind` parameter (defaulting to `\"probe\"`) and a `watchBoot` flag. Probe requests append `&bk=probe` to the query string, while watch\/sync\/peer requests append a `&vn=` version parameter.\n\n- The artifact-fetch helper used by the publish\/read flow likewise now takes `kind` (default `\"probe\"`) and `watchBoot`, alongside its existing `relayOnly`\/`agentPeer`\/`syncLive`\/`speculative` options, feeding into the same underlying request.\n\n**Why** Making the request kind and boot-watching explicit lets the different artifact flows (probing, watching, syncing, peer requests) be distinguished consistently wherever an artifact request is made.\n\n- Area: Artifacts\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}