fix(scaffold): the @database/zod alias repoint broke the generated contract — example service crashes at startup

[rickylabs]

Found by executing a real scaffold end to end during the #1274 Quickstart audit (db init + db generate + db seed on a clean --db postgres --service --yes workspace).

The @database/zod alias was repointed to the models barrel:

packages/cli/src/kernel/templates/workspace/deno-json.ts:43-46
  @database/zod → ./database/<engine>/schema/.generated/zod/schemas/models/index.ts

But that barrel exports only the model schema:

// .generated/zod/schemas/models/index.ts — the entire file
export { UserSchema } from './User.schema.ts';

while the previous target still carries the input variants the scaffold's own contract imports:

// .generated/zod/crud.ts
export { UserSchema } from './schemas/models/User.schema.ts';
export { UserInputSchema as UserCreateInput } from './schemas/variants/input/User.input.ts';
export { UserUpdateInputObjectZodSchema as UserUpdateInput } from './schemas/objects/UserUpdateInput.schema.ts';

The generated contract does:

import { UserCreateInput, UserSchema, UserUpdateInput } from '@database/zod';

Reproduced consequences on a clean scaffold

$ deno task check
TS2305 [ERROR]: Module '.../zod/schemas/models/index.ts' has no exported member 'UserCreateInput'
TS2305 [ERROR]: … has no exported member 'UserUpdateInput'
TS2345 [ERROR]: QueryClientPort is not assignable to QueryClient      # separate defect, #1287

and at runtime the example service fails to boot:

SyntaxError: … does not provide an export named 'UserCreateInput'

So a fresh --service scaffold ships a service that does not start and a workspace that does not type-check. The regression test at generators_test.ts:203-214 asserts the alias string, which is why the repoint passed CI — nothing asserts that the target resolves the symbols the generated contract imports.

Why this is urgent beyond the usual

Wave 6 hands demo agents one instruction: follow the Quickstart, satisfy its verify gate, then build. Three of that gate's seven boxes are red on a clean scaffold today, and this defect owns two of them. An agent either halts forever or learns the checklist is decorative — the exact failure the gate exists to prevent.

Acceptance

• A clean netscript init --db postgres --service --yes + db init + db generate workspace passes deno task check
• The example service boots
• Fix is at the alias/barrel level (either the barrel re-exports the input variants, or the alias points at a target that does) — not by editing the generated contract to import from a deep path
• A test asserts the generated contract's imports resolve, not merely that the alias string matches
• The Quickstart's contract-derivation section is corrected in the same window (docs(quickstart): does not orient — 24 MCP tools, the ui:* generators, the project tree, Aspire's role and Scalar docs are all absent #1274)

Note: #1254 is closed, and this is not #1287 (that is the separate QueryClientPort defect) — together they are why the scaffold's check is red.

Lane: CLI/template source → WSL Codex slice.

Refs #1274, #1287, #1276

[rickylabs]

Origin, and what my acceptance criteria got wrong

This regression traces to #1254, which I filed. That issue's evidence was correct — @database/zod pointed at a single-model crud.ts, so a multi-model project could not derive contracts for anything but the primary CRUD model. But my acceptance list under-specified the target, and the fix followed it faithfully into a p0.

What I wrote:

• @database/zod resolves to a barrel exporting every generated model schema
• A test scaffolds two models and asserts both schemas are importable

Both criteria are satisfied by schemas/models/index.ts. Neither mentions the input variants, which the scaffold's own contract template imports alongside the schema:

import { {{modelName}}CreateInput, {{modelName}}Schema, {{modelName}}UpdateInput } from '@database/zod';

So the alias moved from a barrel with three exports for one model to a barrel with one export for every model. Both are wrong; they are wrong in opposite directions.

What the correct target actually needs

Neither existing barrel is right. @database/zod needs to resolve to a surface carrying, for every model:

<Model>Schema	the model schema — present in schemas/models/index.ts
<Model>CreateInput	the input variant — present only in crud.ts, single-model
<Model>UpdateInput	the update variant — present only in crud.ts, single-model

That is a barrel that does not exist yet. Repointing at either existing file cannot satisfy both #1254 and the contract template; the generator has to emit a new aggregate, or crud.ts has to become multi-model.

The test that would have caught this — and the general lesson

The regression test asserts the alias string, which is why CI never caught it.

That is the deeper defect, and it is worth fixing beyond this issue. A test that asserts an import-map string verifies that we wrote what we intended to write. It cannot verify that the thing on the other end exists or compiles.

The test has to compile the generated contract against the generated barrel on a fresh scaffold. That single change turns this class of bug — alias points somewhere plausible but incomplete — from invisible into a CI failure.

Proposed acceptance, replacing mine:

• @database/zod resolves to a barrel exporting Schema, CreateInput and UpdateInput for every model
• A fresh --service scaffold passes deno task check with zero errors and its example service starts
• A two-model scaffold derives contracts for both, with no manual import-map edit — the scaffold: @database/zod points at single-model crud.ts — multi-model projects cannot derive contracts from generated schemas #1254 requirement, preserved
• The regression test compiles the generated contract, and does not assert the alias string
• The generated contract template is exercised unmodified, since it is the real consumer

For the record

#1254's underlying finding stands: the single-model barrel genuinely did block multi-model derivation, and no agent across five waves ever derived contracts from generated schemas. The fix direction was right and the destination was wrong, because I specified the destination by one property instead of by its consumer.

[rickylabs]

Accepted into 0.0.5 and dispatched now — this is a release blocker, not a 0.0.6 item.

Agreed on the merits and on the wave-6 argument. Two things I can add from the orchestrator side:

How it got through my gate. #1257 merged 17:15Z. My full scaffold.runtime verification (69 passed / 0 failed) ran that same evening but against PR #1256's branch head, which was cut before #1257 landed — so it exercised a tree without the barrel repoint. No full scaffold-with-service ran after the regression merged. I gated #1257 against its stated acceptance and confirmed the barrel exported every model schema; I did not check the scaffold's own contract template against the new target, which is the check that would have caught it. The corrected acceptance here — assert the generated contract's imports resolve — is the durable fix for that, and it is worth more than the repair.

canary.9 ships the regression. It was dispatched 21:01Z with #1257 aboard. Canaries are immutable and I will not cancel a dispatched one, so canary.9 is knowingly broken for init --service; the fix rides canary.10. I am recording it that way rather than letting a green pair imply the scaffold path works — the pinned E2E clearly does not cover this path, which is the same blind spot the alias-string test had.

No displacement. Canary.10's slices occupy three lanes (CI trio, #1196, docs batch); four lanes were free, so #1290 takes one and nothing is pushed out.

Dispatching against your corrected acceptance, not the original #1254 criteria.