@boopkit/cli 0.7.1 → 0.8.1

package/profiles/development/profile.md

@@ -4,6 +4,7 @@ description: Development skills only — for a project with no application domai
 defaultCapabilities:
   # Development
   - coding
+  - typescript
   - testing
   - project-mgmt
   - product-design
@@ -31,16 +32,17 @@ but they are all developed the same way.
 
 ## What You Get
 
-Six capabilities, all of them `type: development` —
-pure skill bundles that guide agent behaviour,
-plus the handful of dev dependencies those skills assume:
+Seven capabilities, all of them `type: development` —
+skill bundles that guide agent behaviour,
+plus the TypeScript toolchain those skills assume:
 
 - **coding** — development conventions, code style, commit and debugging skills
-- **testing** — Jest setup, test utilities, the TDD-Lite workflow
-- **project-mgmt** — beads issue tracking and planning skills
-- **product-design** — feature requirements, engineering design, documentation skills
+- **typescript** — the TypeScript toolchain: Jest with ts-jest, `tsconfig.test.json`, and the `test` and `typecheck` scripts
+- **testing** — the testing principles and the TDD-Lite workflow
+- **project-mgmt** — beads issue tracking, planning, issue sweeps and stray disposition
+- **product-design** — feature requirements, engineering design, documentation and knowledge backfill skills
 - **skills** — skill authoring, discovery and maintenance
-- **workflows** — the end-to-end development and writing workflows
+- **workflows** — the end-to-end code development and audit workflows
 
 No web layer, no API layer, no service layer, no database.
 Add any of those with `boop add` if the project grows an application domain.
@@ -72,7 +74,7 @@ and the consequence is deliberate: `boop init --profile development` is refused
 with a message pointing at the two ways this profile is actually meant to be used —
 name it in an existing project's `.boop/config.json`,
 or `boop add` these capabilities one at a time.
-The capabilities carry their own dependencies (`jest`, `ts-jest`, `beads`),
+The capabilities carry their own dependencies (`typescript` brings `jest` and `ts-jest`, and `project-mgmt` brings `beads`),
 so nothing is lost by having no kernel to merge them from.
 
 ### No reference/

package/profiles/web-app/profile.md

@@ -9,6 +9,7 @@ defaultCapabilities:
   - database
   # Development
   - coding
+  - typescript
   - testing
   - project-mgmt
   - product-design
@@ -86,11 +87,12 @@ The `web-app` profile ships all of the following capabilities by default:
 - **services** — Service layer scaffolding, auto-discovery, and design skills
 - **database** — PostgreSQL with Prisma ORM, migrations, and seeding
 
-**Development capabilities** — pure skill bundles that guide agent behavior:
+**Development capabilities** — skill bundles that guide agent behavior, and the toolchain they assume:
 - **coding** — Development conventions and code style skills
-- **testing** — Jest setup, test utilities, TDD workflow skills
-- **project-mgmt** — Beads issue tracking, planning skills
-- **product-design** — Feature requirements, design thinking skills
+- **typescript** — The TypeScript toolchain: Jest with ts-jest, `tsconfig.test.json`, and the `test` and `typecheck` scripts
+- **testing** — Testing principles and the TDD-Lite workflow skills
+- **project-mgmt** — Beads issue tracking, planning, issue sweeps and stray disposition
+- **product-design** — Feature requirements, design thinking and knowledge backfill skills
 - **skills** — Skill authoring and maintenance
 
 **Demo:**

package/profiles/web-app/reference/message-queue-patterns.ref.md

@@ -26,28 +26,23 @@ await MessageQueueService.publish('batch-ready', [message1, message2]);
 - **Error recovery**: If `publish()` catches an error (e.g., channel closed), it resets connection state and returns `false` — the next call will reconnect
 - **Shutdown**: The publish connection is tracked and closed by `close()` alongside the listener connection
 
-### Publishing to a queue that does not exist
+### Publishing to a queue that does not exist yet
 
-`publish()` does not declare the queue; only `listen()` does.
-A broker confirms a message that it cannot put in any queue and then discards it,
-so a publish to a name that no consumer has ever listened on returns `true` and the message is lost.
+`publish()` declares the queue's topology (main, `.retry` and `.failed` queues and their exchanges) before its first publish to it on a connection, exactly as `listen()` does,
+so a message published before the consumer has ever run is kept until the consumer attaches.
 
-Pass `{ mandatory: true }` as the third argument when the publisher cannot be sure the queue exists:
-when the name is composed at run time (for example with `targetPrefix`),
-or when the publisher can start before the consumer ever has.
+- Each queue is declared once per publish connection; concurrent first publishes share the declaration, and a queue a consumer in the same process already declared with the same arguments is not declared again
+- The declaration runs on a short-lived channel, so a refused one (`PRECONDITION_FAILED`, when the arguments differ from the existing queue's) fails that publish alone: it is logged with the queue's name and `publish()` returns `false`
+- Pass the consumer's `queueArguments` in the third argument whenever the consumer declares any:
 
 ```typescript
-const queued = await MessageQueueService.publish('batch-ready', message, { targetPrefix, mandatory: true });
+const queued = await MessageQueueService.publish('batch-ready', message, { targetPrefix, queueArguments: BATCH_QUEUE_ARGUMENTS });
 if (!queued) {
   // Not queued anywhere: record or report it.
 }
 ```
 
-- The message is sent with the AMQP `mandatory` flag, and the broker returns it when no queue has the destination's name
-- `publish()` then logs `publish to "<queue>" was returned by the broker: no queue has that name` and returns `false`
-- The connection state is **not** reset in this case — the connection is healthy, and the next `publish()` reuses it
-- A queue that exists but has no consumer running still takes the message; the option reports a missing queue, not a missing worker
-- Without the option, `publish()` is unchanged
+- `{ mandatory: true }` still makes the broker return a message no queue took; after the declaration that means a real fault, such as a queue deleted by hand, and `publish()` returns `false` without resetting the connection
 
 ### Why persistent (not per-call)
 

package/src/templates/kernel/tests/app.test.ts.hbs

@@ -0,0 +1,17 @@
+import app from '../src/app';
+
+describe('app', () => {
+  it('exports a valid Express application', () => {
+    expect(app).toBeDefined();
+    expect(typeof app.get).toBe('function');
+    expect(typeof app.post).toBe('function');
+    expect(typeof app.use).toBe('function');
+  });
+
+  it('has JSON and URL-encoded body parsing enabled', () => {
+    const stack = (app as any).router?.stack ?? (app as any)._router?.stack ?? [];
+    const layerNames = stack.map((layer: any) => layer.name);
+    expect(layerNames).toContain('jsonParser');
+    expect(layerNames).toContain('urlencodedParser');
+  });
+});