@rawsql-ts/ztd-cli 0.19.0 → 0.20.0

package/README.md

@@ -111,7 +111,7 @@ How to read that layout:
 * `src/domain`, `src/application`, and `src/presentation/http` are where generic WebAPI work should begin.
 * `src/infrastructure/persistence`, `src/sql`, `src/catalog`, and `ztd/ddl` are the ZTD-owned persistence side.
 * `tests/generated` is generated output. Recreate it with `ztd ztd-config` instead of editing it manually.
-* `.ztd/agents` contains managed AI guidance so a later prompt such as "WebAPI化して" does not accidentally jump straight into persistence-specific rules.
+* Optional AI guidance files can be generated when you explicitly request them, but the default scaffold stays focused on consumer-facing project files.
 
 ## Choose The Right Happy Path
 
@@ -158,8 +158,6 @@ After `ztd init` you should see:
 | `tests/smoke.validation.test.ts`  | Validator integration smoke test                                |
 | `tests/support/testkit-client.ts` | Driver wiring placeholder                                       |
 | `src/catalog/specs/`              | Spec and runtime files for the smoke contract                   |
-| `CONTEXT.md`                      | Agent-focused project invariants and recommended command usage  |
-| `.ztd/agents/manifest.json`       | Managed AI guidance index with security notices and entrypoints |
 
 ```bash
 # 4. Generate test types from the demo DDL
@@ -184,6 +182,7 @@ All smoke tests should pass. You now have a working ZTD project.
 
 * Replace the demo DDL with your own schema, or inspect an explicit target with `npx ztd ddl pull --url <target>`
 * Re-run `npx ztd ztd-config` whenever DDL changes (or use `--watch`)
+* Add AI guidance files only if you want them in the repo: `npx ztd init --with-ai-guidance`
 * Install visible AGENTS files only if you want them in the repo: `npx ztd agents install`
 * Wire a real driver in `tests/support/testkit-client.ts` (see [adapter-node-pg](../adapters/adapter-node-pg) for Postgres)
 * Write domain tests against generated `TestRowMap` types
@@ -214,6 +213,7 @@ mkdir /tmp/my-ztd-dogfood && cd /tmp/my-ztd-dogfood
 node "<LOCAL_SOURCE_ROOT>/packages/ztd-cli/dist/index.js" init \
   --workflow empty \
   --validator zod \
+  --with-ai-guidance \
   --local-source-root "<LOCAL_SOURCE_ROOT>"
 
 # 4. Install the scaffolded dependencies
@@ -314,7 +314,7 @@ Most write-capable commands support `--dry-run` and `--json <payload>` for autom
 
 | Command | Description |
 |---------|-------------|
-| `ztd init` | Create a ZTD-ready project layout (DDL folder, config, test stubs). Flags: `--yes`, `--workflow <pg_dump\|empty\|demo>`, `--validator <zod\|arktype>`, `--with-sqlclient`, `--with-app-interface`, `--local-source-root <path>` |
+| `ztd init` | Create a ZTD-ready project layout (DDL folder, config, test stubs). Flags: `--yes`, `--workflow <pg_dump\|empty\|demo>`, `--validator <zod\|arktype>`, `--with-ai-guidance`, `--with-sqlclient`, `--with-app-interface`, `--local-source-root <path>` |
 | `ztd agents install` | Materialize visible `AGENTS.md` files from the managed templates |
 | `ztd agents status` | Report internal/visible AGENTS state and drift signals |
 | `ztd ztd-config` | Generate `TestRowMap` and layout from DDL files. Flags: `--watch`, `--quiet` |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rawsql-ts/ztd-cli",
-  "version": "0.19.0",
+  "version": "0.20.0",
   "description": "DB-agnostic scaffolding and DDL helpers for Zero Table Dependency projects",
   "main": "dist/index.js",
   "bin": {

package/templates/README.md

@@ -29,7 +29,7 @@ Next steps:
 8. Use `ztd model-gen --probe-mode live`, `ztd ddl pull`, or `ztd ddl diff` only for explicit target inspection by passing `--url` or a complete `--db-*` flag set.
 9. If you generate migration SQL artifacts, apply them with your deployment tooling instead of `ztd-cli`.
 
-If this project was scaffolded with `ztd init --local-source-root <monorepo-root>`, first run `pnpm install` (or `pnpm install --ignore-workspace` when nested under another `pnpm-workspace.yaml`), then `pnpm typecheck`, then `pnpm test`, then `pnpm ztd ztd-config`. For generated QuerySpecs, prefer `pnpm ztd model-gen --probe-mode ztd --import-style relative` so imports keep using the local shim.
+If this project was scaffolded with `ztd init --local-source-root <monorepo-root>`, first run `pnpm install` (or `pnpm install --ignore-workspace` when nested under another `pnpm-workspace.yaml`), then `pnpm typecheck`, then `pnpm test`, then `pnpm ztd ztd-config`. The scaffold keeps `@rawsql-ts/sql-contract` as a normal package import even in local-source developer mode.
 
 For schema-change impact checks, `npx ztd query uses` defaults to the `impact` view. Table add / column add checks usually work with the default scan, while table rename / column rename / column type change checks often benefit from `--exclude-generated` so review-only specs under `src/catalog/specs/generated` do not add noise. The flag is optional and does not change the default scan set.
 

package/templates/README.webapi.md

@@ -35,4 +35,4 @@ Next steps:
 8. Treat `ddl pull` and `ddl diff` as explicit target inspection commands that require `--url` or a complete `--db-*` flag set.
 9. If you generate migration SQL artifacts, apply them outside `ztd-cli`.
 
-If this project was scaffolded with `ztd init --local-source-root <monorepo-root>`, first run `pnpm install` (or `pnpm install --ignore-workspace` when nested under another `pnpm-workspace.yaml`), then `pnpm typecheck`, then `pnpm test`, then `pnpm ztd ztd-config`. For generated QuerySpecs, prefer `pnpm ztd model-gen --probe-mode ztd --import-style relative` so imports keep using the local shim.
+If this project was scaffolded with `ztd init --local-source-root <monorepo-root>`, first run `pnpm install` (or `pnpm install --ignore-workspace` when nested under another `pnpm-workspace.yaml`), then `pnpm typecheck`, then `pnpm test`, then `pnpm ztd ztd-config`. The scaffold keeps `@rawsql-ts/sql-contract` as a normal package import even in local-source developer mode.

package/templates/src/catalog/runtime/_coercions.local-source.ts

@@ -1,30 +0,0 @@
-// Runtime coercions run BEFORE validator schemas.
-// See docs/recipes/mapping-vs-validation.md for pipeline details.
-export function normalizeTimestamp(value: unknown, fieldName?: string): Date {
-  const fieldLabel = fieldName?.trim() ? ` for "${fieldName}"` : '';
-
-  // Preserve valid Date instances while rejecting invalid dates eagerly.
-  if (value instanceof Date) {
-    if (Number.isNaN(value.getTime())) {
-      throw new Error(`Invalid Date value${fieldLabel}.`);
-    }
-    return value;
-  }
-
-  // Parse driver-returned timestamp strings after trimming transport whitespace.
-  if (typeof value === 'string') {
-    const trimmed = value.trim();
-    if (!trimmed) {
-      throw new Error(`Expected a non-empty timestamp string${fieldLabel}.`);
-    }
-
-    const timestamp = Date.parse(trimmed);
-    if (Number.isNaN(timestamp)) {
-      throw new Error(`Invalid timestamp string${fieldLabel}: "${value}".`);
-    }
-    return new Date(timestamp);
-  }
-
-  const actualType = value === null ? 'null' : typeof value;
-  throw new Error(`Expected Date or timestamp string${fieldLabel}, received ${actualType}.`);
-}

package/templates/src/local/sql-contract.ts

@@ -1 +0,0 @@
-export * from '@rawsql-ts/sql-contract';