@slowcook-ai/cli 0.6.5 → 0.6.8

package/dist/commands/testgen/prompts.d.ts

@@ -1,12 +1,18 @@
 /**
  * System prompt for the test-gen agent. Takes a frozen spec as input; emits a
- * single Vitest integration test file.
+ * single Vitest integration test file in the tier-1 shape defined in
+ * docs/plans/0.7-testgen-two-tier.md §4.1.
  *
- * The agent does NOT read the consumer's src/. It tests the spec's contract,
- * not the implementation. HTTP-style integration tests (fetch the API, assert
- * on the response) are preferred because they don't need the implementation
- * to exist at test-collection time — they fail at runtime if the endpoint is
- * missing, which is exactly the "red test" state brewing wants.
+ * 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.
+ *
+ * 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).
  */
 export declare const TESTGEN_SYSTEM: (projectContext: string) => string;
 //# sourceMappingURL=prompts.d.ts.map

package/dist/commands/testgen/prompts.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../../src/commands/testgen/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,eAAO,MAAM,cAAc,GAAI,gBAAgB,MAAM,WA0CwK,CAAC"}
+{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../../src/commands/testgen/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;AAEH,eAAO,MAAM,cAAc,GAAI,gBAAgB,MAAM,WA2E0J,CAAC"}

package/dist/commands/testgen/prompts.js

@@ -1,43 +1,82 @@
 /**
  * System prompt for the test-gen agent. Takes a frozen spec as input; emits a
- * single Vitest integration test file.
+ * single Vitest integration test file in the tier-1 shape defined in
+ * docs/plans/0.7-testgen-two-tier.md §4.1.
  *
- * The agent does NOT read the consumer's src/. It tests the spec's contract,
- * not the implementation. HTTP-style integration tests (fetch the API, assert
- * on the response) are preferred because they don't need the implementation
- * to exist at test-collection time — they fail at runtime if the endpoint is
- * missing, which is exactly the "red test" state brewing wants.
+ * 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.
+ *
+ * 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).
  */
 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.
 
+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.
+
 ## Input
 
-You will receive:
 - The full spec YAML (already validated, frozen).
-- Project context (stack config, existing test style snippets if present).
+- Project context below: \`.brewing/context.md\` conventions, package.json, existing test style references, existing mock helpers.
 
 ## Output format
 
-Emit ONLY the TypeScript test file contents. No prose before or after, no code fences. Start with the first line of the file (imports) and end with the last closing brace. The file must:
+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.
+
+## Required 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.
+
+2. **Mock helpers** for every external service the handler consumes. Helpers live at \`tests/helpers/mocks/<service>.ts\` and expose intent-level options. Example:
+
+   \`\`\`ts
+   import { mockSupabase, resetMocks } from "@/tests/helpers/mocks";
+
+   const supabase = mockSupabase({
+     auth: { user: { id: "u1", verified: false } },
+     insert: { table: "rewos", returning: { id: "rewo1" } },
+   });
+   \`\`\`
+
+   If the project context below does NOT list a helper you need, emit the test anyway but leave a \`TODO(helper): describe shape\` comment at the top of the file listing the missing helpers. Do not write the helper body yourself — that's out of scope for this prompt. An operator will hand-author it.
+
+3. **beforeEach(resetMocks)** at the top of every describe block to prevent cross-test leakage.
+
+4. **Request objects built in-process**, not fetched. Example:
+
+   \`\`\`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 res = await POST(req);
+   expect(res.status).toBe(201);
+   \`\`\`
+
+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".
+
+## Forbidden patterns (mechanically rejected)
 
-- Be valid TypeScript that Vitest can collect (imports resolve or fail at RUNTIME, not at collection — prefer HTTP calls over direct function imports).
-- Use \`describe\` / \`it\` from Vitest.
-- Use \`beforeEach\` / \`afterEach\` for setup/teardown if needed.
-- Include ALL acceptance scenarios as \`it\` blocks, named to match the scenario (Given/When/Then phrasing preserved).
-- Include invariant checks as separate \`it\` blocks where they can be asserted via HTTP.
-- Include negative tests for every error response listed in \`api_contract\` (403, 429, 404, etc.).
-- Include edge cases for each invariant (e.g., "exactly at the boundary").
+The test file must NOT contain any of these. Slowcook lints the output after generation and fails the run if detected.
 
-## Stylistic conventions
+- \`vi.mock(\`  — use project helper functions instead.
+- \`vi.fn(\`   — helpers encapsulate the fakes; callers supply intent, not function bodies.
+- \`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.
 
-- One describe block per API endpoint or per cohesive topic.
-- Test names use natural language matching acceptance scenarios, e.g. \`it("rejects a self-report with 409", ...)\`.
-- Use \`fetch\` (global) for HTTP calls — avoid importing app code. This keeps tests runnable even before implementation exists.
-- Prefer environment variables for the API base URL (fall back to \`http://localhost:3000\`). Expose via a local const.
-- If the spec references a DB table, DO NOT import the DB client directly. Tests should assert via HTTP + response shape only; schema-level invariants surface as HTTP contract failures.
-- Mark deliberately-incomplete assertions with a \`// TODO(story-N): ...\` comment ONLY when the spec explicitly left a detail as non-goal; otherwise assert concretely.
+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.
 
 ## Project context (consumer's conventions)
 
@@ -45,10 +84,10 @@ ${projectContext}
 
 ## Do NOT
 
-- Read or reference files outside the spec. Don't import types from the consumer's source code. The spec is the contract.
+- 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\` — these are caught by slowcook's static scan and will fail the manifest check.
+- Use \`test.skip\` / \`test.todo\`.
 
-Produce a complete, parseable file that, when executed against an unimplemented API, fails with clear messages (status code mismatches, response shape mismatches). That is the desired "red" state brewing will turn green.`;
+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.`;
 //# 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;;;;;;;;;GASG;AAEH,MAAM,CAAC,MAAM,cAAc,GAAG,CAAC,cAAsB,EAAE,EAAE,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAiCxD,cAAc;;;;;;;;;6NAS6M,CAAC"}
+{"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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAkExD,cAAc;;;;;;;;;+MAS+L,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@slowcook-ai/cli",
-  "version": "0.6.5",
+  "version": "0.6.8",
   "description": "CLI for the slowcook brewing harness",
   "license": "MIT",
   "author": "aminazar",
@@ -35,10 +35,11 @@
   "dependencies": {
     "@anthropic-ai/sdk": "^0.32.1",
     "@octokit/rest": "^21.0.2",
+    "ts-morph": "^24.0.0",
     "yaml": "^2.6.0",
     "zod": "^3.23.8",
-    "@slowcook-ai/stack-ts": "^0.6.2",
     "@slowcook-ai/core": "^0.5.0",
+    "@slowcook-ai/stack-ts": "^0.6.2",
     "@slowcook-ai/forge-github": "^0.5.0"
   },
   "publishConfig": {