Backlog: CodeScene plugin (gated on REST-API signal) + dev-standard policy layer; CodeRabbit out of scope

[sandstream]

Backlog — captured from a design discussion on where third-party code-quality tools fit in kit's model. No commitment to build yet; this records the decision + the gating question.

kit's model (the ruler)

kit is the deterministic gate that runs your scanners and folds their results into one report. Plugins = adapters that ingest a tool's findings. Zero LLM calls, local-first.

Decisions

• CodeScene → thin plugin, gated on API signal. The MCP server was tried and "didn't give much" — expected, since MCP is a conversational surface, the wrong shape for a gate. What kit wants is the CodeScene REST API's code-health score / hotspot delta as a crisp threshold-able pass/fail, folded in exactly like the snyk/wiz plugins. Worth a thin plugin only if the API exposes a tractable value. Otherwise skip — don't build an adapter for noise.
  • Open question (decide before building): what do CodeScene's REST endpoints actually expose (code-health, hotspots, per-commit deltas)? Verify before committing to a plugin.
• CodeRabbit → out of scope. Do not absorb. It's an LLM-based PR-review agent living in the GitHub/PR layer — contrary to kit's "zero LLM calls, one deterministic verdict" identity. Complementary, not a component: CodeRabbit reviews the PR, kit gates the environment/supply-chain. Wrapping it would break the identity.
• dev-standard → home for the policy. Clean layering:
  • plugin = data source ("fetch the code-health number").
  • dev-standard = the standard/threshold ("code health ≥ X or fail; hotspots must not grow"). Subjective team policy belongs in dev-standard, not hard-coded into a scanner plugin.

Net

CodeScene as a thin plugin (data source) if its REST API delivers a usable signal, with the threshold expressed in dev-standard (policy). CodeRabbit stays outside kit.

🤖 Generated with Claude Code

https://claude.ai/code/session_015ERHw6bVUz39sAuoQZ1iyg

[sandstream]

Research outcome — the gating question is answered: GO (API exposes a tractable signal)

The open question was "what do CodeScene's REST endpoints actually expose — verify before building." Verified against the CodeScene REST API docs (Enterprise 7.3.x, consistent back to 4.x):

• Endpoint: GET /projects/{id}/analyses/latest/files?order_by=change_frequency&page_size=25
• Returns per file: code_health.current_score (numeric — the threshold-able value), number_of_defects, change_frequency, lines_of_code, name.
• Paged endpoints support a filter param with dot-notation on nested fields (e.g. code_health.current_score).

→ This is precisely the "crisp threshold-able pass/fail" kit wants. A thin plugin is justified: fetch the latest analysis' top hotspots, gate on min(code_health.current_score) ≥ X and/or "hotspot defects must not grow," fold the verdict in like the snyk/wiz plugins. Per the layering decided here, the threshold lives in dev-standard (policy), the plugin is just the data source.

Blocker to actually building it

Needs a CodeScene instance + API token + a real project id to verify the exact response shape and test the adapter end-to-end — not available in this environment. So this moves from "research-gated" to "buildable when credentialed": the API signal is confirmed tractable; implementation + verification waits on access to a CodeScene instance.

CodeRabbit remains out of scope (unchanged).

---

Generated by Claude Code