@dreki-gg/pi-code-reviewer 0.4.0 → 0.5.0

package/extensions/code-reviewer/types.ts

@@ -25,6 +25,116 @@ export type LensResult = {
   _lensSection?: string;
 };
 
+// ── Self-driving review pipeline (Bugbot-style) ──────────────────────────────
+//
+// The tool can run the review itself by driving the session's model through
+// several parallel adversarial passes, bucketing + majority-voting the
+// findings, then validating each survivor — instead of returning a prompt for
+// a single downstream pass. The types below describe that pipeline's data.
+
+/** A finding as emitted by one bug-finding pass (before bucketing). */
+export type RawFinding = {
+  file: string;
+  line?: number;
+  severity: LensSeverity;
+  message: string;
+  /** Optional bug taxonomy tag the pass assigned (e.g. "boundary-input"). */
+  category?: string;
+};
+
+/** A merged bucket of near-duplicate raw findings across passes. */
+export type CandidateFinding = RawFinding & {
+  /** Number of DISTINCT passes that independently surfaced this bucket. */
+  votes: number;
+  /** Indices of the passes that contributed (0-based). */
+  passIndices: number[];
+};
+
+/** A candidate after the validator stage has confirmed or refuted it. */
+export type ValidatedFinding = CandidateFinding & {
+  verdict: 'real' | 'false-positive';
+  /** Validator confidence in `verdict`, 0..1. */
+  confidence: number;
+  justification?: string;
+  /** Distinct model keys whose passes contributed to this finding (for the
+   *  model bake-off: "which model caught this"). */
+  models: string[];
+};
+
+/** Reasoning/thinking effort for a step (mirrors pi-ai's `ThinkingLevel`). */
+export type ReasoningLevel = 'minimal' | 'low' | 'medium' | 'high' | 'xhigh';
+
+/** A per-step model choice in config: either a bare spec string
+ *  ("provider/id", id, or name) or that spec plus a reasoning level. */
+export type ModelSpec = { model: string; reasoning?: ReasoningLevel };
+export type ModelStepConfig = string | ModelSpec;
+
+/** A resolved per-step assignment the pipeline runs against. `key` is either
+ *  {@link DEFAULT_MODEL_KEY} (the session model) or a spec that resolved to a
+ *  real model; `label` is the human display (key + reasoning). */
+export type ModelAssignment = {
+  key: string;
+  label: string;
+  reasoning?: ReasoningLevel;
+};
+
+export type ModelPlan = {
+  /** Assignment for each pass, length === `passes` (round-robin from config). */
+  passes: ModelAssignment[];
+  /** Assignment for the validator stage. */
+  validator: ModelAssignment;
+};
+
+/** Counts describing what the pipeline did, for transparency in the report. */
+export type PipelineTelemetry = {
+  passes: number;
+  passFindingCounts: number[];
+  buckets: number;
+  candidates: number;
+  validated: number;
+  droppedFalsePositives: number;
+  droppedLowSignal: number;
+  failedPasses: number;
+  /** Model key used for each pass (parallel to pass index). */
+  passModels: string[];
+  /** Model key used for the validator stage. */
+  validatorModel: string;
+};
+
+export type PipelineResult = {
+  findings: ValidatedFinding[];
+  telemetry: PipelineTelemetry;
+};
+
+/** Tunables for the self-driving pipeline (all overridable in config). */
+export type ReviewPipelineConfig = {
+  /** Parallel adversarial bug-finding passes. 0 disables the pipeline
+   *  (falls back to returning a single-pass review prompt). */
+  passes: number;
+  /** Run the validator stage that falsifies each surviving candidate. */
+  validate: boolean;
+  /** Min distinct passes a NOTE-severity bucket needs to survive pre-validation
+   *  (blockers/warnings are never dropped for low votes). */
+  minVotes: number;
+  /** Max passes run concurrently. */
+  concurrency: number;
+  /** Base sampling temperature; each pass adds a small deterministic jitter so
+   *  passes diverge instead of collapsing onto identical reasoning. */
+  temperature: number;
+  /** Hard cap on findings returned (safety valve against runaway output). */
+  maxFindings: number;
+  /** Model for ALL passes — a spec string or `{ model, reasoning }`. Omitted →
+   *  session model. Overridden per-pass by {@link passModels}. */
+  passModel?: ModelStepConfig;
+  /** Models rotated round-robin across passes — run the same diff through
+   *  several models/reasoning levels in one review (a bake-off). Overrides
+   *  `passModel`. */
+  passModels?: ModelStepConfig[];
+  /** Model for the validator stage — a spec string or `{ model, reasoning }`.
+   *  Omitted → session model. */
+  validateModel?: ModelStepConfig;
+};
+
 // NOTE: findings + summary on LensResult describe what the agent produces in
 // its follow-up message; the tool/command layer emits a review *task*, it does
 // not parse findings back into a rendered report.
@@ -38,4 +148,6 @@ export type ReviewConfig = {
   /** Max lens tools run in parallel. Tools are deduped across lenses first,
    *  so this bounds the distinct command set, not lens count. */
   toolConcurrency: number;
+  /** Self-driving pipeline tunables (see {@link ReviewPipelineConfig}). */
+  review: ReviewPipelineConfig;
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dreki-gg/pi-code-reviewer",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "Multi-lens code review extension for pi — configurable review criteria per project",
   "keywords": [
     "pi-package"

package/skills/code-review/lenses/code-quality.md

@@ -10,11 +10,25 @@ Evaluates changes for correctness, dead code introduction, and adherence to proj
 - Are there any obvious bugs or logic errors?
 - Does the code avoid known anti-patterns for the project's framework?
 
+### Adversarial inputs (enumerate, don't assume)
+For each changed function, construct the edge inputs that break it rather than
+trusting the happy path or the surrounding comment:
+- `null` / `undefined` / `NaN` / `Infinity` / `-0` / `""` / `[]` / `{}` / huge /
+  negative / duplicate / out-of-order / unicode.
+- Numeric-type guards that the wrong value defeats: `typeof NaN === "number"`,
+  `typeof null === "object"`, `0`/`""`/`NaN` as falsy, `JSON.parse` of
+  attacker input. Prefer `Number.isFinite` / explicit checks.
+- **Claim-vs-code audit:** every comment or test that asserts an invariant
+  ("non-numeric falls through", "never empty") — find the input that violates it
+  and confirm the code actually enforces the claim.
+- Off-by-one, boundary indices, wrong id/key space, missing `await`, swallowed
+  errors, unhandled rejection, cancellation/abort paths.
+
 ## Tools
 - `bun run typecheck`
 - `bun run lint`
 
 ## Severity
-- blocker: Type errors, unresolved imports, obvious bugs, unhandled error paths
-- warning: New lint violations, unused code, inconsistent naming
+- blocker: Type errors, unresolved imports, obvious bugs, unhandled error paths, an edge input (NaN/empty/boundary) that crashes or corrupts on a path users hit
+- warning: New lint violations, unused code, inconsistent naming, an unguarded edge input on a lower-risk path, a comment/test claim the code does not actually honor
 - note: Style suggestions, minor improvements