@taskless/cli 0.11.0 → 0.11.2

package/dist/schemas/index.d.ts

@@ -0,0 +1,106 @@
+/**
+ * Public entry for `@taskless/cli/schemas`.
+ *
+ * The shapes this CLI's `--json` output is produced from, as data. A consumer
+ * parsing `taskless verify --json` validates against the schema the CLI emits
+ * from, rather than against an interface it hand-wrote by reading our output
+ * once.
+ *
+ * ## Why this is published
+ *
+ * This is `@taskless/cli/layout`'s argument applied to the other half of the
+ * contract. A hand-written interface is a copy that nothing checks: the CLI can
+ * add a field, change what one means, or extend an enum, and the copy stays
+ * confidently wrong until something downstream misbehaves. The Cloud eval team
+ * is doing exactly that today against the `verify` envelope.
+ *
+ * ## What this is NOT
+ *
+ * Not an SDK. Nothing here performs verification, and no `verify()` or `test()`
+ * is exported. Both spawn a vendored platform binary — ast-grep or Vale — so
+ * anywhere a function call could run them, `npx @taskless/cli verify --json`
+ * runs too: the export would buy a call site, not a capability, while making
+ * internal signatures public. The CLI stays the execution surface; this
+ * describes what it says.
+ *
+ * Nothing here reaches the filesystem, a process, the network or the command
+ * tree, so a Worker can import it — and the build fails rather than emitting an
+ * entry whose graph reaches a host capability. `writeJsonError` is deliberately
+ * absent for that reason: it writes to stdout, and a consumer asking what shape
+ * an error takes should not thereby acquire something that emits one.
+ *
+ * ## Zod is bundled, and that is the point
+ *
+ * This entry ships its own copy of zod rather than resolving the consumer's.
+ * That follows from the build's standing rule for library entries — everything
+ * but node builtins is bundled — but it is also the behaviour we want, so do
+ * not "fix" it by making zod external.
+ *
+ * **A consumer's zod is not ours.** Marking it external would make validation
+ * depend on whichever version resolved on the other side, so the same payload
+ * could parse there and not here, and the schema would stop being a statement
+ * about what this CLI emits. Bundling makes `parse()` answer with our zod's
+ * semantics wherever it runs.
+ *
+ * **And `parse()` is stronger than a JSON Schema of the same shape.** It
+ * strips: `parse({ ok: true, rules: [], surprise: 1 })` returns
+ * `{ ok: true, rules: [] }`, where a JSON Schema validator hands back the
+ * object it was given, unknown keys included. Every schema here is plain today
+ * — objects, enums, arrays, optionals — so a JSON Schema rendering would lose
+ * little beyond that. It is the moment we add a refinement that the difference
+ * bites, and it would bite silently: the rendering would go on validating a
+ * weaker shape while claiming to describe this one.
+ *
+ * `z.toJSONSchema()` therefore stays unexported, and the criterion is the
+ * TRANSPORT rather than the consumer's language. JSON Schema is what you reach
+ * for when the schema itself has to travel — when the far side can receive JSON
+ * and nothing else, so a description of the shape is the most that fits. That
+ * is not this boundary. A consumer here takes a dependency on our schema files,
+ * which means it can assert the payload rather than assert against a
+ * description of the payload, and rendering ours down to what a JSON transport
+ * could carry would give that up in exchange for nothing.
+ */
+export { 
+/**
+ * `taskless verify --json` and `taskless test --json`.
+ *
+ * One envelope for both, because the commands share an implementation and
+ * differ only in what they run against each rule.
+ */
+outputSchema as verifyTestOutputSchema, } from "./verify-test.js";
+export { 
+/**
+ * The layered detail behind one ast-grep rule's verification — schema
+ * validation, Taskless requirement checks, and `sg test`, kept separate
+ * rather than flattened into `verifyTestOutputSchema`'s single envelope.
+ *
+ * Not what `taskless verify --json` or `taskless test --json` print. Both
+ * commands compute this internally via `verifyRule()` and then flatten it
+ * before printing anything, so there is no current CLI invocation that
+ * emits this shape verbatim. A command that did — `taskless rule verify
+ * <id> --json` — existed once and was removed when rule addressing moved
+ * from id to path, because an id can name a rule under two engines and a
+ * path cannot (see `resolve-path.ts`). This schema describes the pre-
+ * flattening detail that command used to print, unchanged since.
+ */
+verifyOutputSchema, 
+/** The same, for a Vale rule — a different shape, discriminated on `engine`. */
+valeVerifyOutputSchema, } from "./rules-verify.js";
+export type { 
+/**
+ * A constraint `verify` or `test` enforces beyond an engine's own schema.
+ *
+ * The type of the entries in `@taskless/cli/reference.json`'s
+ * `constraints[]`, so a consumer reading the corpus and a consumer reading a
+ * rejection are working from one definition.
+ */
+RuleConstraint, 
+/** One constraint a rule broke, as `violations[]` carries it. */
+RuleViolation, 
+/** The id of a constraint this CLI publishes. */
+RuleConstraintId, } from "../rules/constraints.js";
+export type { 
+/** The stable code an error envelope carries under `--json`. */
+CLIErrorCode, 
+/** The envelope itself. Not every `--json` failure is a rule result. */
+CLIErrorEnvelope, } from "../types/errors.js";

package/dist/schemas/rules-create.d.ts

@@ -11,6 +11,7 @@ export declare const outputSchema: z.ZodObject<{
     ruleId: z.ZodString;
     rules: z.ZodArray<z.ZodString>;
     files: z.ZodArray<z.ZodString>;
+    notices: z.ZodOptional<z.ZodArray<z.ZodString>>;
 }, z.core.$strip>;
 /** Error schema for `taskless rule create --json` on failure */
 export declare const errorSchema: z.ZodObject<{

package/dist/schemas/rules-improve.d.ts

@@ -14,6 +14,7 @@ export declare const outputSchema: z.ZodObject<{
     requestId: z.ZodString;
     rules: z.ZodArray<z.ZodString>;
     files: z.ZodArray<z.ZodString>;
+    notices: z.ZodOptional<z.ZodArray<z.ZodString>>;
 }, z.core.$strip>;
 /** Error schema for `taskless rule improve --json` on failure */
 export declare const errorSchema: z.ZodObject<{

package/dist/schemas/rules-verify.d.ts

@@ -0,0 +1,67 @@
+import { z } from "zod";
+export declare const schemaOutputSchema: z.ZodObject<{
+    astGrepSchema: z.ZodRecord<z.ZodString, z.ZodUnknown>;
+    tasklessRequirements: z.ZodObject<{
+        requiredFields: z.ZodArray<z.ZodString>;
+        rules: z.ZodArray<z.ZodObject<{
+            name: z.ZodString;
+            description: z.ZodString;
+        }, z.core.$strip>>;
+    }, z.core.$strip>;
+    examples: z.ZodArray<z.ZodObject<{
+        description: z.ZodString;
+        rule: z.ZodRecord<z.ZodString, z.ZodUnknown>;
+    }, z.core.$strip>>;
+}, z.core.$strip>;
+export declare const verifyOutputSchema: z.ZodObject<{
+    engine: z.ZodLiteral<"sg">;
+    success: z.ZodBoolean;
+    ruleId: z.ZodString;
+    schema: z.ZodObject<{
+        valid: z.ZodBoolean;
+        errors: z.ZodArray<z.ZodString>;
+        notice: z.ZodOptional<z.ZodString>;
+    }, z.core.$strip>;
+    requirements: z.ZodObject<{
+        valid: z.ZodBoolean;
+        errors: z.ZodArray<z.ZodString>;
+    }, z.core.$strip>;
+    tests: z.ZodObject<{
+        valid: z.ZodBoolean;
+        errors: z.ZodArray<z.ZodString>;
+        passed: z.ZodNumber;
+        failed: z.ZodNumber;
+    }, z.core.$strip>;
+}, z.core.$strip>;
+/**
+ * Vale verification output.
+ *
+ * Deliberately not squeezed into the ast-grep shape. `sg` verification is three
+ * layers over a rule file and its test cases; Vale verification is one question
+ * asked of two fixture buckets — did every `fail/` document fire, did every
+ * `pass/` document stay quiet. Mapping the second onto `schema`/`requirements`/
+ * `tests` would invent two empty layers and lose the fixture coverage, which is
+ * the part that catches a rule that was never really verified.
+ *
+ * `engine` is the discriminant. A consumer branches on it before reading
+ * anything else, and adding an engine cannot silently change the meaning of a
+ * field another engine already emits.
+ */
+export declare const valeVerifyOutputSchema: z.ZodObject<{
+    engine: z.ZodLiteral<"vale">;
+    success: z.ZodBoolean;
+    ruleId: z.ZodString;
+    fixtures: z.ZodEnum<{
+        both: "both";
+        "pass-only": "pass-only";
+        "fail-only": "fail-only";
+        none: "none";
+    }>;
+    missingFailures: z.ZodArray<z.ZodString>;
+    unexpectedFindings: z.ZodArray<z.ZodString>;
+    notice: z.ZodOptional<z.ZodString>;
+}, z.core.$strip>;
+export declare const verifyErrorSchema: z.ZodObject<{
+    success: z.ZodLiteral<false>;
+    error: z.ZodString;
+}, z.core.$strip>;

package/dist/schemas/verify-test.d.ts

@@ -0,0 +1,22 @@
+import { z } from "zod";
+/** Output schema for `taskless verify --json` and `taskless test --json`. */
+export declare const outputSchema: z.ZodObject<{
+    ok: z.ZodBoolean;
+    rules: z.ZodArray<z.ZodObject<{
+        engine: z.ZodEnum<{
+            sg: "sg";
+            vale: "vale";
+            runtime: "runtime";
+        }>;
+        ruleId: z.ZodString;
+        ok: z.ZodBoolean;
+        errors: z.ZodArray<z.ZodString>;
+        violations: z.ZodArray<z.ZodObject<{
+            constraintId: z.ZodString;
+            message: z.ZodString;
+        }, z.core.$strip>>;
+        ran: z.ZodOptional<z.ZodBoolean>;
+        refused: z.ZodOptional<z.ZodString>;
+        notice: z.ZodOptional<z.ZodString>;
+    }, z.core.$strip>>;
+}, z.core.$strip>;