{"server":"io.kernelscan/kernelscan","count":3,"changes":[{"tool":"update_product","kind":"changed","observed_at":"2026-10-06T20:51:49.722Z","fields":["description"],"description_before":"Update a product owned by the caller. Re-runs analysis if the\n        kernel_version, arch, or referenced .config changed.\n\n        To change the .config, first POST the new file to\n        ``/api/configs/uploads`` (see ``create_product`` for the curl recipe)\n        and pass the returned ``config_upload_id`` here. Leave\n        ``config_upload_id`` as ``None`` to keep the existing .config.\n        ``factor_ids=None`` leaves factor selections untouched; an empty\n        list clears them. Same tier gates as PUT /api/products/{id}.\n\n        A change that re-runs analysis (``kernel_version``, ``arch``, or the\n        ``.config``) spends one unit of the team's shared monthly analysis\n        allowance and can fail with the same durable \"Monthly analysis limit\n        reached … [429]\" quota error as ``create_product`` (distinct from the\n        transient rate-limit 429 — don't retry it). A rename / description /\n        factor-only edit runs no analysis and is free.\n\n        ``kernel_version`` takes the same forms as in ``create_product``: a\n        stable version, or a CIP release / full ``uname -r`` such as\n        ``4.19.325-cip136-rt50``, whose ``-cipN`` counter decides which CIP\n        fixes apply. A changed version string the analysis cannot read fails\n        with 400 and changes nothing; re-sending the stored value is always\n        accepted. A CIP release must stay on the base its ``.config`` header\n        names: whichever of the two the update changes is checked against the\n        other ([400], before the upload is consumed).\n        ","description_after":"Update a product owned by the caller. Re-runs analysis if the\n        kernel_version, arch, or referenced .config changed.\n\n        To change the .config, first POST the new file to\n        ``/api/configs/uploads`` (see ``create_product`` for the curl recipe)\n        and pass the returned ``config_upload_id`` here. Leave\n        ``config_upload_id`` as ``None`` to keep the existing .config.\n        ``factor_ids=None`` leaves factor selections untouched; an empty\n        list clears them. Same tier gates as PUT /api/products/{id}.\n\n        A change that re-runs analysis (``kernel_version``, ``arch``, or the\n        ``.config``) spends one unit of the team's shared monthly analysis\n        allowance and can fail with the same durable \"Monthly analysis limit\n        reached … [429]\" quota error as ``create_product`` (distinct from the\n        transient rate-limit 429 — don't retry it). A rename / description /\n        factor-only edit runs no analysis and is free; the product's VEX is re-evaluated\n        against the new factors in the background (not metered), so ``get_product`` /\n        ``get_product_vex`` show the new verdicts a few seconds later.\n\n        ``kernel_version`` takes the same forms as in ``create_product``: a\n        stable version, or a CIP release / full ``uname -r`` such as\n        ``4.19.325-cip136-rt50``, whose ``-cipN`` counter decides which CIP\n        fixes apply. A changed version string the analysis cannot read fails\n        with 400 and changes nothing; re-sending the stored value is always\n        accepted. A CIP release must stay on the base its ``.config`` header\n        names: whichever of the two the update changes is checked against the\n        other ([400], before the upload is consumed).\n        ","description_similarity":0.915,"before_hash":"d7fe50307eda60e0308b36266a02f6ef","after_hash":"56664501481db96bc93e6c003ea8a800"},{"tool":"update_product","kind":"changed","observed_at":"2026-10-04T19:49:12.225Z","fields":["description"],"description_before":"Update a product owned by the caller. Re-runs analysis if the\n        kernel_version, arch, or referenced .config changed.\n\n        To change the .config, first POST the new file to\n        ``/api/configs/uploads`` (see ``create_product`` for the curl recipe)\n        and pass the returned ``config_upload_id`` here. Leave\n        ``config_upload_id`` as ``None`` to keep the existing .config.\n        ``factor_ids=None`` leaves factor selections untouched; an empty\n        list clears them. Same tier gates as PUT /api/products/{id}.\n\n        A change that re-runs analysis (``kernel_version``, ``arch``, or the\n        ``.config``) spends one unit of the team's shared monthly analysis\n        allowance and can fail with the same durable \"Monthly analysis limit\n        reached … [429]\" quota error as ``create_product`` (distinct from the\n        transient rate-limit 429 — don't retry it). A rename / description /\n        factor-only edit runs no analysis and is free.\n        ","description_after":"Update a product owned by the caller. Re-runs analysis if the\n        kernel_version, arch, or referenced .config changed.\n\n        To change the .config, first POST the new file to\n        ``/api/configs/uploads`` (see ``create_product`` for the curl recipe)\n        and pass the returned ``config_upload_id`` here. Leave\n        ``config_upload_id`` as ``None`` to keep the existing .config.\n        ``factor_ids=None`` leaves factor selections untouched; an empty\n        list clears them. Same tier gates as PUT /api/products/{id}.\n\n        A change that re-runs analysis (``kernel_version``, ``arch``, or the\n        ``.config``) spends one unit of the team's shared monthly analysis\n        allowance and can fail with the same durable \"Monthly analysis limit\n        reached … [429]\" quota error as ``create_product`` (distinct from the\n        transient rate-limit 429 — don't retry it). A rename / description /\n        factor-only edit runs no analysis and is free.\n\n        ``kernel_version`` takes the same forms as in ``create_product``: a\n        stable version, or a CIP release / full ``uname -r`` such as\n        ``4.19.325-cip136-rt50``, whose ``-cipN`` counter decides which CIP\n        fixes apply. A changed version string the analysis cannot read fails\n        with 400 and changes nothing; re-sending the stored value is always\n        accepted. A CIP release must stay on the base its ``.config`` header\n        names: whichever of the two the update changes is checked against the\n        other ([400], before the upload is consumed).\n        ","description_similarity":0.657,"before_hash":"1f11cf0cb2b6acbfadf1192f785b364b","after_hash":"d7fe50307eda60e0308b36266a02f6ef"},{"tool":"create_product","kind":"changed","observed_at":"2026-10-04T19:49:12.225Z","fields":["description"],"description_before":"Create a new product, run analysis, and return its initial stats.\n\n        ``config_upload_id`` references a previously-staged .config that the\n        caller POSTed to ``/api/configs/uploads`` over plain HTTP — the LLM\n        does NOT emit the config text itself (a real kernel .config is\n        ~100–200 KB and exceeds a single tool-call output budget). Workflow:\n\n        1. Caller / wrapper script:\n           ``curl -H \"Authorization: Bearer ks_live_...\" \\\n                  -F \"config_file=@.config\" \\\n                  https://kernelscan.io/api/configs/uploads``\n           returns ``{config_upload_id, sha256, size_bytes, expires_at}``.\n        2. Pass that ``config_upload_id`` into this tool.\n\n        Uploads are per-user, single-use, and expire 30 minutes after upload.\n        Same gates as POST /api/products: free can't create products; paid\n        plans are capped at their resolved product limit — read it (and any\n        per-account override) from ``whoami.product_limit`` rather than assuming\n        a fixed per-tier number. ``factor_ids`` are silently ignored unless the\n        plan allows security factors (``whoami.can_use_factors``). Re-using a\n        product name returns 409.\n\n        Creating a product RUNS an analysis, so it spends one unit of the\n        team's SHARED monthly analysis allowance (``whoami.monthly_analyses_used``\n        / ``monthly_analyses_limit``). When the allowance is exhausted the tool\n        fails with \"Monthly analysis limit reached (…/month) [429]\". This is a\n        durable monthly quota — NOT the transient per-call rate limit that also\n        surfaces as 429: it will not clear until next month, so report it to the\n        user instead of retrying. Check ``whoami`` before a batch of creates.\n        ","description_after":"Create a new product, run analysis, and return its initial stats.\n\n        ``config_upload_id`` references a previously-staged .config that the\n        caller POSTed to ``/api/configs/uploads`` over plain HTTP — the LLM\n        does NOT emit the config text itself (a real kernel .config is\n        ~100–200 KB and exceeds a single tool-call output budget). Workflow:\n\n        1. Caller / wrapper script:\n           ``curl -H \"Authorization: Bearer ks_live_...\" \\\n                  -F \"config_file=@.config\" \\\n                  https://kernelscan.io/api/configs/uploads``\n           returns ``{config_upload_id, sha256, size_bytes, expires_at}``.\n        2. Pass that ``config_upload_id`` into this tool.\n\n        Uploads are per-user, single-use, and expire 30 minutes after upload.\n        Same gates as POST /api/products: free can't create products; paid\n        plans are capped at their resolved product limit — read it (and any\n        per-account override) from ``whoami.product_limit`` rather than assuming\n        a fixed per-tier number. ``factor_ids`` are silently ignored unless the\n        plan allows security factors (``whoami.can_use_factors``). Re-using a\n        product name returns 409.\n\n        Creating a product RUNS an analysis, so it spends one unit of the\n        team's SHARED monthly analysis allowance (``whoami.monthly_analyses_used``\n        / ``monthly_analyses_limit``). When the allowance is exhausted the tool\n        fails with \"Monthly analysis limit reached (…/month) [429]\". This is a\n        durable monthly quota — NOT the transient per-call rate limit that also\n        surfaces as 429: it will not clear until next month, so report it to the\n        user instead of retrying. Check ``whoami`` before a batch of creates.\n\n        ``kernel_version`` is the kernel's release. For a stable kernel that is\n        its version (``6.6.67``). For a CIP SLTS kernel pass its CIP release or\n        the full ``uname -r``: ``4.19.325-cip136``, ``4.19.325-cip136-rt50``;\n        a trailing local suffix such as ``-yocto-standard`` is accepted and\n        ignored. The ``-cipN`` counter decides which of CIP's own backported\n        fixes apply, so pass it whenever the device runs a CIP kernel — a bare\n        ``4.19.325`` is analysed as the final 4.19 stable release (the\n        ``.config`` never names the ``-cipN``). The known CIP releases of a\n        series are listed by ``GET /api/kernel-releases?flavor=cip&series=4.19``\n        (add ``&rt=1`` for the RT tree). The returned\n        ``kernel_release`` shows how the string was read (``flavor``, ``base``,\n        ``series``, ``cip``, ``rt``, ``local``; null when the string is no\n        release). Surrounding whitespace is trimmed. A version string the\n        analysis cannot read (e.g. ``4.19.325cip136``, or anything non-ASCII)\n        fails with \"Unrecognized kernel version\" [400] before anything is\n        created or the upload is consumed.\n\n        A CIP release must be on the stable base the uploaded ``.config``'s\n        header names (the header shows the exact base; a CIP tag never changes\n        it): ``4.19.300-cip90`` with a ``4.19.325`` config fails with \"… is\n        based on 4.19.300, but the .config header says 4.19.325\" [400]. This is\n        checked before the upload is consumed, so the same upload can be used\n        again with the right release. A stable version, or a ``.config``\n        without a version header, is not checked.\n        ","description_similarity":0.642,"before_hash":"89e90e06b666295bc0a2ba76db732ff9","after_hash":"ed6e25ba20fad4564f27163664674109"}],"next_before":null,"next_actions":[]}