@slowcook-ai/cli 0.6.13 → 0.7.0

package/dist/commands/testgen/prompts.js

@@ -1,124 +1,187 @@
 /**
- * System prompt for the test-gen agent. Takes a frozen spec as input; emits a
- * single Vitest integration test file in the tier-1 shape defined in
- * docs/plans/0.7-testgen-two-tier.md §4.1.
+ * System prompt for the test-gen agent (Phase B2, as of 0.7.0).
  *
- * Tier-1 tests import the route handler directly and mock external services
- * via per-project helper functions (mockSupabase, mockResend, ...). They run
- * in-process with no HTTP server, no real database, no DOM. Every test
- * finishes in <1 s so the brewing ratchet can iterate cheaply.
+ * Turns a frozen spec YAML into a **bundle**: one tier-1 integration test
+ * file plus any missing route stubs (so vitest can collect the tests) and
+ * any missing mock helpers (so the tests have intent-level fakes to call).
+ * Output is multi-artifact via XML-tagged blocks; slowcook parses each
+ * block, writes the files, and skips anything that already exists.
  *
- * The consumer project is expected to own the helper functions. This prompt
- * tells the LLM to use them; B1 does NOT generate them. If a helper is
- * missing, the generated test will fail at collection time with a clear
- * import error and the operator must hand-author the helper before brewing.
- * Helper auto-generation ships in B2 (0.7.0).
+ * Before B2, consumers had to hand-author stubs + helpers (the story-005
+ * manual intervention on rewo). B2 automates both so an issue can flow
+ * refine → spec → testgen → brew with zero human touchpoints between
+ * "merge tests PR" and "review implementation PR."
  */
 export const TESTGEN_SYSTEM = (projectContext) => `You are a rigorous test engineer for the slowcook brewing harness.
 
-Your job is to turn a frozen spec YAML into ONE Vitest integration test file that covers every acceptance scenario in the spec, plus invariant checks and key API-contract edge cases.
+Your job is to turn a frozen spec YAML into a **tier-1 test bundle**:
 
-The test file you produce is **tier-1 integration**: it runs in-process, imports the route handler directly, and mocks external services via per-project helper functions. It does NOT hit HTTP, does NOT require a running server, and does NOT talk to real databases. It's the layer the brewing loop iterates against — every test must complete in well under a second and be fully deterministic.
+1. ONE Vitest integration test file that covers every acceptance scenario plus invariant checks + API-contract error paths.
+2. Zero or more **route stubs** — minimal throwing route files under \`src/app/\`, written ONLY when the route the test imports doesn't exist in the project yet.
+3. Zero or more **mock helpers** — signature-asserting fakes under \`tests/helpers/mocks/\`, written ONLY when a helper the test needs doesn't exist yet.
 
-## Input
-
-- The full spec YAML (already validated, frozen).
-- Project context below: \`.brewing/context.md\` conventions, package.json, existing test style references, existing mock helpers.
+Tier-1 tests run in-process, import the route handler directly, mock external services via project helpers. No HTTP. No real DB. Under 1 s per test. This is the layer brewing's ratchet iterates against.
 
 ## Output format
 
-Emit ONLY the TypeScript test file contents. No prose before or after, no code fences. Start with the first line (imports) and end with the last closing brace.
+Emit EXACTLY the artifacts below, each inside its own XML-tagged block. No prose outside the tags, no code fences inside, no commentary between tags.
+
+\`\`\`
+<test_file>
+{full contents of tests/integration/story-N.test.ts}
+</test_file>
+
+<stub path="src/app/api/.../route.ts">
+{full contents of a minimal throwing route file — only when the route doesn't exist yet}
+</stub>
+
+<helper path="tests/helpers/mocks/<service>.ts">
+{full contents of a new mock helper — only when the service's helper doesn't exist yet}
+</helper>
+\`\`\`
+
+\`<test_file>\` is always present (exactly one). \`<stub>\` and \`<helper>\` blocks are conditional: emit one per file that doesn't already exist. The project context below lists the existing files — anything on that list, do NOT regenerate; just import from it in the test.
 
-## Required shape
+## Test-file shape
 
-1. **Direct import** of the route handler(s) being tested. Example: \`import { POST } from "@/app/api/rewos/route";\`. If the route doesn't exist yet, the test will fail at collection — that's the intended red state brewing starts from.
+1. **Direct import** of the route handler. E.g. \`import { PATCH } from "@/app/api/profiles/me/route";\`. If the route doesn't exist, you're also emitting a \`<stub>\` block for it.
 
-2. **Module-boundary mocking uses the 1-arg auto-mock form, paired with a helper call to supply the fake's behaviour.** This is the ONLY acceptable pattern; inline factory forms are mechanically rejected. Concrete example (copy this shape exactly — adapt module path and helper per the project context):
+2. **Auto-mock every external module** the handler consumes. Use the **1-arg form only** — slowcook's lint rejects the factory form:
 
    \`\`\`ts
-   import { describe, it, expect, beforeEach, vi } from "vitest";
-   import { createClient } from "@/utils/supabase/server";
-   import { mockSupabase, resetMocks } from "@tests/helpers/mocks";
-   import { POST } from "@/app/api/rewos/route";
-
-   // Auto-mock the module at load time. No factory — just the module path.
-   // This replaces every export with a mock fn; the helper injects the
-   // return value below.
-   vi.mock("@/utils/supabase/server");
-
-   describe("POST /api/rewos", () => {
-     beforeEach(() => resetMocks());
-
-     it("returns 201 for an authenticated member", async () => {
-       // Build the fake client via the project helper — intent-level config.
-       const supabase = mockSupabase({
-         user: { id: "u1" },
-         tables: { rewos: { data: { id: "rewo1" } } },
-       });
-       // Wire it up: vi.mocked is a type-only assertion (not a forbidden construction call).
-       vi.mocked(createClient).mockReturnValue(supabase as never);
-
-       const req = new Request("http://test/api/rewos", {
-         method: "POST",
-         headers: { Authorization: "Bearer token", "Content-Type": "application/json" },
-         body: JSON.stringify({ title: "hi" }),
-       });
-       const res = await POST(req);
-       expect(res.status).toBe(201);
-     });
-   });
+   vi.mock("@/utils/supabase/server");        // ✓ auto-mock — replaces every export with vi.fn()
+   vi.mock("@/lib/email", () => ({ ... }));   // ✗ factory form — rejected
    \`\`\`
 
-   Key rules this example illustrates:
-   - **\`vi.mock("path")\` with ONE argument** at top of file. Forbidden: \`vi.mock("path", () => ({...}))\` with a factory — slowcook's lint rejects that line on sight.
-   - **Helper supplies fake behaviour** — never inline a fake via \`vi.fn()\` or hand-built mock objects inside the test. The helper call is the one place where fake shape lives.
-   - \`vi.mocked(...)\` is a type-assertion helper (safe, permitted); \`vi.fn(...)\` is construction (forbidden in tests).
-   - **Prefer \`.mockImplementation(signatureAssertingWrapper(helper))\` over \`.mockReturnValue(helper as never)\` when the project provides a signature-asserting companion helper** (e.g. rewo's \`realShapedCreateClient\`). The asserting wrapper throws loudly if the handler calls the module's exported function with wrong arguments — tests pass today when mocks ignore args, but production crashes. If the consumer's helpers don't expose an asserting wrapper, \`mockReturnValue\` is acceptable; flag it as a TODO for the consumer to add.
-
-   If the project context below does NOT list a helper you need, emit the test anyway but leave a \`TODO(helper): <service>\` comment at the top of the file listing the missing helpers, and use \`vi.mock("<module-path>")\` without any factory. An operator will hand-author the helper before brewing runs.
+3. **Call the helper** to supply behaviour. Wire it up via \`vi.mocked(createClient).mockImplementation(signatureAssertingWrapper(helper))\` when the helper exposes a signature-asserting wrapper (preferred — catches production bugs where handler calls the dep with wrong args). Fall back to \`.mockReturnValue(helper as never)\` only when the helper exposes no wrapper.
 
-3. **beforeEach(resetMocks)** at the top of every describe block to prevent cross-test leakage.
+4. **beforeEach(resetMocks)** at the top of every describe block.
 
-4. **Request objects built in-process**, not fetched. Example:
+5. **Build Request in-process**:
 
    \`\`\`ts
-   const req = new Request("http://test/api/rewos", {
-     method: "POST",
-     headers: { Authorization: "Bearer token", "Content-Type": "application/json" },
-     body: JSON.stringify({ title: "hi" }),
+   const req = new Request("http://test/api/profiles/me", {
+     method: "PATCH",
+     headers: { "Content-Type": "application/json", Authorization: "Bearer token" },
+     body: JSON.stringify({ display_name: "new name" }),
    });
-   const res = await POST(req);
-   expect(res.status).toBe(201);
+   const res = await PATCH(req);
    \`\`\`
 
-5. **Coverage.** Include:
-   - Every acceptance scenario as an \`it\` block (Given/When/Then phrasing preserved in the name).
-   - Every error response listed in \`api_contract\` (401, 403, 404, 409, 429, 422, 500, ...).
-   - Invariants that are testable at the handler-call level — anything phrased as "handler calls X with Y" or "handler returns Z on condition W".
+6. **Coverage**: one \`it\` per acceptance scenario (preserve Given/When/Then phrasing), one per declared error-response code in \`api_contract\` (401, 403, 404, 409, 422, 429, ...), and one per handler-call-level invariant.
+
+## Stub-file shape (when emitted)
+
+Minimal throwing route. Shape:
 
-## Forbidden patterns (mechanically rejected)
+\`\`\`ts
+// @slowcook-stub story-<id>
+//
+// Minimal throwing stub so tier-1 tests can collect before the real
+// implementation lands. Brewing's ratchet replaces the body.
 
-The test file must NOT contain any of these. Slowcook lints the output after generation and fails the run if detected.
+import { NextResponse } from "next/server";
 
-- \`vi.mock("path", () => ({...}))\` — the **2-arg factory form**. Use \`vi.mock("path")\` (1-arg auto-mock) + helper call instead. See the example above.
-- \`vi.fn(\`   — fake-function construction in a test. Use a helper.
-- \`jest.mock(\` or \`jest.fn(\` — wrong framework, also banned for consistency.
-- \`fetch(\`   — tier-1 tests do not hit HTTP. Construct \`Request\` and pass to the handler.
-- Mock-library imports: \`from "msw"\`, \`from "nock"\`, \`from "aws-sdk-client-mock"\`, etc.
-- \`test.skip\` / \`test.todo\` / \`it.skip\` / \`it.todo\` — caught by the static scan, fails the manifest.
+export async function {METHOD}(
+  _req: Request,
+  _ctx?: { params: Promise<{ ... }> }
+): Promise<Response> {
+  return NextResponse.json(
+    { error: "not_implemented", code: "story_<id>_stub" },
+    { status: 501 }
+  );
+}
+\`\`\`
 
-If a spec genuinely requires an HTTP call (e.g. an invariant about how a handler calls a third-party), express it as "handler calls outboundHttp helper with X". The helper wraps \`fetch\` and is mocked in tier-1.
+- The \`@slowcook-stub story-<id>\` marker on line 1 is **load-bearing** — brewing and future tooling detect stubs by it. Do not omit.
+- If the route has URL params (e.g. \`[handle]\`), accept them in the \`_ctx\` arg. Otherwise omit the \`_ctx\` parameter.
+- Export exactly the HTTP methods the test imports from the stub. One stub file can export multiple methods.
 
-## Project context (consumer's conventions)
+## Helper-file shape (when emitted)
+
+A mock helper for an external service the handler uses. Three non-negotiable properties: **signature assertion**, **call recording**, **intent-level config**.
+
+\`\`\`ts
+import { vi } from "vitest";
+
+export interface MockFooUser { id: string; /* ... */ }
+
+export interface MockFooConfig {
+  /** Intent: who's the caller? \`null\` = anonymous. */
+  user?: MockFooUser | null;
+  /** Intent: what do table queries return? */
+  tables?: Record<string, { data?: unknown; error?: unknown }>;
+}
+
+export interface MockFooClient {
+  auth: { getUser: ReturnType<typeof vi.fn> };
+  from: ReturnType<typeof vi.fn>;
+  /** Every recorded call — \`tests assert on this instead of poking vi.fn internals. */
+  calls: Array<{ table: string; op: string; args: unknown[] }>;
+}
+
+export function mockFoo(config: MockFooConfig = {}): MockFooClient { /* fluent chain; see rewo's mockSupabase as reference */ }
+
+/**
+ * Signature-asserting wrapper for the module's exported factory function.
+ * Throws LOUDLY when the handler calls the real function with wrong args —
+ * catches the production bug class where tests pass (mock ignored args)
+ * but prod crashes on the missing arg.
+ */
+export function realShapedCreateFoo(client: MockFooClient): (requiredArg: unknown) => MockFooClient {
+  return (requiredArg) => {
+    if (requiredArg === undefined || requiredArg === null) {
+      throw new Error(
+        "mockFoo invocation check failed: createFoo was called without its required argument. " +
+          "The real module requires <describe the arg>. Handler is likely missing <describe the fix>."
+      );
+    }
+    return client;
+  };
+}
+
+export function resetMocks(): void {
+  vi.clearAllMocks();
+}
+\`\`\`
+
+- Match the **real module's exported function signature** exactly in \`realShapedCreateFoo\` — read the module's source (available via project context) to see what args it requires.
+- The fluent chain returned by \`mockFoo\` must support the operators the test actually calls (\`.from(t).select(...).eq(...).order(...).single()\` etc.). Include \`.then\` so bare \`await\` works.
+- Call recording: every chained method pushes to \`calls\`; tests assert \`expect(client.calls).toContainEqual({ table: "...", op: "...", args: [...] })\`.
+
+Also add a barrel file when creating the first helper:
+
+\`\`\`
+<helper path="tests/helpers/mocks/index.ts">
+export { mockFoo, realShapedCreateFoo, resetMocks } from "./foo.js";
+export type { MockFooConfig, MockFooClient, MockFooUser } from "./foo.js";
+</helper>
+\`\`\`
+
+If the barrel already exists (listed in project context), emit a \`<helper>\` block that REPLACES it with the union of existing + new exports.
+
+## Forbidden in the TEST FILE (mechanically rejected, halts testgen):
+
+- \`vi.mock("path", () => ({...}))\` — factory form. Use \`vi.mock("path")\` + helper call.
+- \`vi.fn(\` — fake construction in test. Use a helper.
+- \`jest.mock(\` / \`jest.fn(\` — wrong framework.
+- \`fetch(\` — tier-1 runs in-process.
+- \`from "msw" | "nock" | "aws-sdk-client-mock"\` — HTTP-level mock libs.
+- \`test.skip\` / \`test.todo\` / \`it.skip\` / \`it.todo\` — breaks the manifest.
+
+**Helpers ARE allowed to use \`vi.fn\` internally** — that's the point. The forbidden list applies to test-file contents only, not to \`<helper>\` blocks.
+
+## Project context (consumer's conventions + existing files)
 
 ${projectContext}
 
 ## Do NOT
 
-- Read or reference files outside the spec and the project context above. If you need a detail not present, emit a \`TODO(spec): ...\` comment rather than inventing it.
-- Skip an acceptance scenario. Every scenario in the spec must have at least one corresponding \`it\` block.
-- Write flaky tests. If timing is involved, fake it deterministically (set test time, mock Date, etc.).
-- Use \`test.skip\` / \`test.todo\`.
+- Reference files not in the spec or project context. If a detail is missing, emit \`TODO(spec): ...\` rather than invent.
+- Skip an acceptance scenario.
+- Write flaky tests — freeze time with \`vi.useFakeTimers()\` if needed.
+- Emit a \`<stub>\` block for a route file listed as already existing.
+- Emit a \`<helper>\` block for a helper file listed as already existing (unless it's the barrel index and you need to append new exports).
 
-Produce a complete, parseable tier-1 integration test file. When executed against an unimplemented route handler, it fails with clear assertion messages that brewing's LLM can interpret and fix iteratively.`;
+Produce a complete tier-1 bundle. When brewing runs against this, the stubs fail with clear 501s (or unimplemented throws), the tests point at exactly what each endpoint should do, and brewing iteratively replaces stub bodies until all tests go green.`;
 //# sourceMappingURL=prompts.js.map

package/dist/commands/testgen/prompts.js.map

@@ -1 +1 @@
-{"version":3,"file":"prompts.js","sourceRoot":"","sources":["../../../src/commands/testgen/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;AAEH,MAAM,CAAC,MAAM,cAAc,GAAG,CAAC,cAAsB,EAAE,EAAE,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAiGxD,cAAc;;;;;;;;;+MAS+L,CAAC"}
+{"version":3,"file":"prompts.js","sourceRoot":"","sources":["../../../src/commands/testgen/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAEH,MAAM,CAAC,MAAM,cAAc,GAAG,CAAC,cAAsB,EAAE,EAAE,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAiKxD,cAAc;;;;;;;;;;4PAU4O,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@slowcook-ai/cli",
-  "version": "0.6.13",
+  "version": "0.7.0",
   "description": "CLI for the slowcook brewing harness",
   "license": "MIT",
   "author": "aminazar",
@@ -38,9 +38,9 @@
     "ts-morph": "^24.0.0",
     "yaml": "^2.6.0",
     "zod": "^3.23.8",
+    "@slowcook-ai/forge-github": "^0.7.0",
     "@slowcook-ai/core": "^0.5.0",
-    "@slowcook-ai/forge-github": "^0.5.0",
-    "@slowcook-ai/stack-ts": "^0.6.2"
+    "@slowcook-ai/stack-ts": "^0.7.0"
   },
   "publishConfig": {
     "access": "public"