fullstack: honor --server / serviceFramework (Express|Fastify) instead of hardcoding Hono

[dan-matthew]

Summary

--server express (CLI) / serviceFramework: "express" (MCP / schema) correctly overrides the HTTP framework for node-service, but is ignored by the fullstack preset. Full-stack always scaffolds Hono.

That makes preset + flag overrides look broken from the agent / web configurator path, even though the option exists and is documented.

Repro

# Works — Express
npx create-packkit node-service demo-svc --server express --no-install --no-git
# → package.json has express; src/app.ts imports express

# Broken — still Hono
npx create-packkit fullstack demo-fs --server express --no-install --no-git
# → apps/server still depends on hono + @hono/node-server
# → summary stack still lists "Hono"

Same via MCP: packkit_preview({ preset: "fullstack", options: { serviceFramework: "express" } }) reports Hono.

Root cause

• CLI alias maps correctly: --server → serviceFramework (src/cli/args.js).
• Standalone service path uses it: src/core/features/service.js branches on cfg.serviceFramework.
• Full-stack path hardcodes Hono in buildFullstack() (src/core/monorepo.js): deps, app.ts, index.ts, tests, and summary stack — never reads cfg.serviceFramework.
• Preset copy also hardcodes the story: PRESET_INFO.fullstack says “Hono API”; options.js help for monorepoLayout: fullstack says “apps/server (Hono)”.

Expected

fullstack + --server express|fastify|hono (and MCP serviceFramework) should generate apps/server with that framework, including:

• dependencies / types
• entry + static-serve wiring for production (web build still served from the API process)
• tests
• README / stack summary / preset descriptions that don’t claim Hono-only

Ideally reuse the same generators as features/service.js (plus fullstack-only static + /api/health + shared package imports) so service and fullstack stay in sync.

Why it matters

Agents and the Packkit MCP surface serviceFramework as a first-class option. When a preset silently ignores overrides, scaffolds look wrong and users assume the wrong option key. Honoring overrides on every preset that emits an HTTP service would make Packkit much more trustworthy for agent-driven scaffolding.

Workaround today

Use node-service --server express for an Express API, or scaffold fullstack and hand-swap the server package to Express.