create_product
Create a new product, run analysis, and return its initial stats.
``config_upload_id`` references a previously-staged .config that the
caller POSTed to ``/api/configs/uploads`` over plain HTTP — the LLM
does NOT emit the config text itself (a real kernel .config is
~100–200 KB and exceeds a single tool-call output budget). Workflow:
1. Caller / wrapper script:
``curl -H "Authorization: Bearer ks_live_..." \
-F "config_file=@.config" \
https://kernelscan.io/api/configs/uploads``
returns ``{config_upload_id, sha256, size_bytes, expires_at}``.
2. Pass that ``config_upload_id`` into this tool.
Uploads are per-user, single-use, and expire 30 minutes after upload.
Same gates as POST /api/products: free can't create products; paid
plans are capped at their resolved product limit — read it (and any
per-account override) from ``whoami.product_limit`` rather than assuming
a fixed per-tier number. ``factor_ids`` are silently ignored unless the
plan allows security factors (``whoami.can_use_factors``). Re-using a
product name returns 409.
Creating a product RUNS an analysis, so it spends one unit of the
team's SHARED monthly analysis allowance (``whoami.monthly_analyses_used``
/ ``monthly_analyses_limit``). When the allowance is exhausted the tool
fails with "Monthly analysis limit reached (…/month) [429]". This is a
durable monthly quota — NOT the transient per-call rate limit that also
surfaces as 429: it will not clear until next month, so report it to the
user instead of retrying. Check ``whoami`` before a batch of creates.
``kernel_version`` is the kernel's release. For a stable kernel that is
its version (``6.6.67``). For a CIP SLTS kernel pass its CIP release or
the full ``uname -r``: ``4.19.325-cip136``, ``4.19.325-cip136-rt50``;
a trailing local suffix such as ``-yocto-standard`` is accepted and
ignored. The ``-cipN`` counter decides which of CIP's own backported
fixes apply, so pass it whenever the device runs a CIP kernel — a bare
``4.19.325`` is analysed as the final 4.19 stable release (the
``.config`` never names the ``-cipN``). The known CIP releases of a
series are listed by ``GET /api/kernel-releases?flavor=cip&series=4.19``
(add ``&rt=1`` for the RT tree). The returned
``kernel_release`` shows how the string was read (``flavor``, ``base``,
``series``, ``cip``, ``rt``, ``local``; null when the string is no
release). Surrounding whitespace is trimmed. A version string the
analysis cannot read (e.g. ``4.19.325cip136``, or anything non-ASCII)
fails with "Unrecognized kernel version" [400] before anything is
created or the upload is consumed.
A CIP release must be on the stable base the uploaded ``.config``'s
header names (the header shows the exact base; a CIP tag never changes
it): ``4.19.300-cip90`` with a ``4.19.325`` config fails with "… is
based on 4.19.300, but the .config header says 4.19.325" [400]. This is
checked before the upload is consumed, so the same upload can be used
again with the right release. A stable version, or a ``.config``
without a version header, is not checked.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| arch | Yes | ||
| name | Yes | ||
| factor_ids | No | ||
| description | No | ||
| kernel_version | Yes | ||
| config_upload_id | Yes |