blitzstrike 1.0.86 → 1.0.87

package/CHANGELOG.md

@@ -5,6 +5,20 @@ All notable changes to Blitz Strike are documented here.
 The format follows [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/).
 
+## [1.0.87] — 2026-09-13
+
+### Added — engagement state (deterministic orchestration bookkeeping)
+
+- New `engagement.ts` module + 4 MCP tools: `engagement_start` (open an
+  engagement), `engagement_phase` (advance the lifecycle phase),
+  `engagement_track` (record each hypothesis as pending/confirmed/rejected),
+  `engagement_status` (deterministic "am I done?" — returns the exact unmet
+  termination criteria instead of a feeling).
+- This is Blitz Strike's own orchestration-state answer: the LLM is the brain;
+  these tools are the hands that keep the phase + hypotheses + termination
+  state so the LLM never relies on its own memory for progress or completion.
+- `bs-orchestrate-engagement` documents the track-state loop.
+
 ## [1.0.86] — 2026-09-13
 
 ### Added — orchestration framework (`orchestration`)

package/dist/index.js

@@ -31848,6 +31848,75 @@ async function activeScan(target, scope = "", mode = "bug-bounty", allowed = und
   return result;
 }
 
+// src/engagement.ts
+var PHASES = ["scope", "recon", "analyze", "deep", "verify", "report"];
+var current = null;
+function ts() {
+  return new Date().toISOString();
+}
+function startEngagement(target, kind = "source") {
+  current = {
+    id: `eng-${Date.now().toString(36)}`,
+    target,
+    kind,
+    phase: "scope",
+    startedAt: ts(),
+    hypotheses: []
+  };
+  return { started: true, ...current };
+}
+function setPhase(phase) {
+  if (!current)
+    return { found: false, error: "no active engagement — call engagement_start first" };
+  const p = phase.toLowerCase().trim();
+  if (!PHASES.includes(p)) {
+    return { found: false, error: `unknown phase '${phase}'`, valid: PHASES };
+  }
+  current.phase = p;
+  return { found: true, phase: current.phase };
+}
+function trackHypothesis(sink, status = "pending") {
+  if (!current)
+    return { found: false, error: "no active engagement — call engagement_start first" };
+  const existing = current.hypotheses.find((h) => h.sink === sink);
+  if (existing)
+    existing.status = status;
+  else
+    current.hypotheses.push({ sink, status });
+  return { found: true, tracked: current.hypotheses.length };
+}
+function engagementStatus() {
+  if (!current)
+    return { found: false, error: "no active engagement — call engagement_start first" };
+  const pending = current.hypotheses.filter((h) => h.status === "pending").length;
+  const confirmed = current.hypotheses.filter((h) => h.status === "confirmed").length;
+  const rejected = current.hypotheses.filter((h) => h.status === "rejected").length;
+  const unmet = [];
+  if (current.phase !== "report") {
+    unmet.push(`phase is '${current.phase}', not 'report' — the report has not been emitted`);
+  }
+  if (pending > 0) {
+    unmet.push(`${pending} hypothesis(es) still pending — verify or reject each one`);
+  }
+  if (current.hypotheses.length === 0) {
+    unmet.push("no hypotheses tracked — nothing was verified");
+  }
+  const idx = PHASES.indexOf(current.phase);
+  const next = idx >= PHASES.length - 1 ? "done" : PHASES[idx + 1];
+  return {
+    found: true,
+    id: current.id,
+    target: current.target,
+    kind: current.kind,
+    phase: current.phase,
+    startedAt: current.startedAt,
+    hypotheses: current.hypotheses,
+    counts: { pending, confirmed, rejected, total: current.hypotheses.length },
+    termination: { done: unmet.length === 0, unmet },
+    next_phase: next
+  };
+}
+
 // src/dataflow.ts
 init_scanner();
 import { readFileSync as readFileSync9 } from "node:fs";
@@ -53986,6 +54055,42 @@ ${statusLine}` : statusLine },
   }, async ({ part }) => {
     return { content: [{ type: "text", text: JSON.stringify(orchestration(part)) }] };
   });
+  server.registerTool("engagement_start", {
+    title: "Start an engagement",
+    description: "ORCHESTRATION: open an engagement and track its state. Call at the start of a full audit so subsequent engagement_phase / engagement_track / engagement_status calls have a state to update. The LLM is the brain; this is the deterministic bookkeeping hand.",
+    inputSchema: {
+      target: string2().describe("The target (source path or live URL)."),
+      kind: _enum(["source", "live"]).optional().describe("source path or live URL. Defaults to source.")
+    }
+  }, async ({ target, kind }) => {
+    return { content: [{ type: "text", text: JSON.stringify(startEngagement(target, kind)) }] };
+  });
+  server.registerTool("engagement_phase", {
+    title: "Advance the engagement phase",
+    description: "ORCHESTRATION: move the engagement to the next lifecycle phase (scope, recon, analyze, deep, verify, report). The phase tracks where the audit is; engagement_status uses it for the termination check.",
+    inputSchema: {
+      phase: string2().describe("One of: scope, recon, analyze, deep, verify, report.")
+    }
+  }, async ({ phase }) => {
+    return { content: [{ type: "text", text: JSON.stringify(setPhase(phase)) }] };
+  });
+  server.registerTool("engagement_track", {
+    title: "Track a hypothesis",
+    description: "ORCHESTRATION: record a hypothesis (a candidate finding keyed by its sink) with its status — pending, confirmed, or rejected. engagement_status derives the termination check from these; an untracked hypothesis is one the LLM has to remember, which is exactly what this avoids.",
+    inputSchema: {
+      sink: string2().describe("The sink / candidate identifier (e.g. 'POST /upload -> eval()')."),
+      status: _enum(["pending", "confirmed", "rejected"]).optional().describe("Defaults to pending.")
+    }
+  }, async ({ sink, status }) => {
+    return { content: [{ type: "text", text: JSON.stringify(trackHypothesis(sink, status)) }] };
+  });
+  server.registerTool("engagement_status", {
+    title: "Engagement status + termination check",
+    description: "ORCHESTRATION: return the current engagement state — phase, hypotheses, counts — and a deterministic termination check (done or the exact unmet criteria). Call this instead of asking yourself 'am I done?'. Also drives blitz_status-style progress.",
+    inputSchema: {}
+  }, async () => {
+    return { content: [{ type: "text", text: JSON.stringify(engagementStatus()) }] };
+  });
   server.registerTool("read_payload", {
     title: "Read a payload collection",
     description: "INTEL: read the full payload collection for a category (or a specific file).",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "blitzstrike",
-  "version": "1.0.86",
+  "version": "1.0.87",
   "description": "Blitz Strike — a universal MCP security-audit toolbelt. BLITZ sweeps the attack surface, EAGLE-EYE traces source-to-sink, STRIKE verifies live. 57 attack chains, 130-tool catalog, intelligence data layer. One server, every agent.",
   "type": "module",
   "bin": {

package/skills/bs-orchestrate-engagement.md

@@ -84,6 +84,12 @@ reference — do not improvise the shape of the engagement:
   the surface is wider than the scan, hypotheses remain unverified, or a
   low-severity finding hasn't been checked for escalation (`chain_links`).
 
+Track the state deterministically so you never rely on your own memory:
+`engagement_start` (open the engagement) → `engagement_phase` (advance the
+phase) → `engagement_track` (record each hypothesis with pending/confirmed/
+rejected) → `engagement_status` (deterministic "am I done?" — returns the exact
+unmet criteria, not a feeling).
+
 ## Orchestration pattern (native plan + sub-agents)
 
 You are the orchestrator — use your platform's native planning and delegation