@tulipes/core 0.1.2 → 0.1.4

package/README.md

@@ -242,18 +242,34 @@ router.get("/users/:id", async (req) => {
 });
 ```
 
-`HttpError` renders `{ error, details? }` with its status. Anything else becomes an anonymous `500 internal server error` — full message only in `development`/`test`.
+`HttpError` renders `{ error, details? }` with its status. Errors raised by express middleware that carry a 4xx `status` are honored too — an oversized body stays a `413`, malformed JSON a `400` — since those describe the caller's request, not your internals. Everything else becomes an anonymous `500 internal server error`, with the real message only in `development`/`test`.
 
 ## The CLI
 
 ```
 tulipes init [dir]           scaffold a new application — boots with zero infrastructure
+tulipes init [dir] --full    ...plus models, bootstrap tasks and queues (needs mongo + redis)
 tulipes sync                 regenerate types/config.d.ts and .env.example
 tulipes env:check            validate env against every meta contract — CI gate, exit 1 on failure
 tulipes new module <name>    scaffold a module (scope auto-detected from siblings)
 tulipes dev [entry]          sync, then run the entry under tsx watch
 ```
 
+The scaffolded `modules/hello` is a worked example of every module
+contract — config factory with lifecycle hooks, ACL grants, routes with
+`HttpError` and permission checks, a controller, a pure helper, and a
+socket namespace. `--full` adds the three that need infrastructure: a
+model, an idempotent bootstrap task, and a queue with its processor.
+
+### Built for AI-assisted work
+
+`tulipes init` also writes a `CLAUDE.md` and eight task-scoped skills under
+`.claude/skills/` — module, env variable, endpoint, model, queue, socket,
+permissions, and reading boot errors. They encode the conventions an agent
+would otherwise guess wrong: declaring variables instead of reaching for
+`process.env`, where global middleware belongs, why `mongoose.model()` is
+never called directly, and how to read an aggregate boot report.
+
 `sync` output — committed, marked generated:
 
 - **`types/config.d.ts`** — augments `KnownVariables` (every variable typed from its spec) and `GlobalConfig` (each namespace typed as its factory's return type via `typeof import(...)` — inference, never execution).

package/dist/cli/init.d.ts

@@ -1,12 +1,21 @@
+export interface InitOptions {
+    /** Also scaffold the contracts that need mongo and redis. */
+    full?: boolean;
+}
 /**
- * `tulipes init [dir]` — scaffold a complete application that boots with
- * ZERO infrastructure: the generated core module declares no MONGO_URI or
- * REDIS_URL, and with no models and no queue files the pipeline skips both
- * engines legitimately. `yarn install && yarn dev` must always succeed on a
- * bare machine; databases arrive later as one meta.variables.json entry.
+ * `tulipes init [dir] [--full]` — scaffold a complete application.
  *
  * Three modules ship: core (sys 0 — env contract, roles, request ids),
- * security (sys 10 — headers, pino logging, body parsing) and hello (the
- * app-tier proof route). Templates live inline, like `new module`.
+ * security (sys 10 — helmet, cors, logging, body parsing) and hello, a
+ * worked example of every module contract.
+ *
+ * By default the app boots with ZERO infrastructure: no MONGO_URI or
+ * REDIS_URL is declared, and with no models and no queue files the
+ * pipeline skips both engines legitimately, so `yarn install && yarn dev`
+ * always succeeds on a bare machine.
+ *
+ * `--full` adds the contracts that cannot work without infrastructure —
+ * models, bootstrap tasks and queues — along with the variables they
+ * require. That app needs mongo and redis running to boot.
  */
-export declare function runInit(rootDir: string, target?: string): Promise<void>;
+export declare function runInit(rootDir: string, target?: string, options?: InitOptions): Promise<void>;