Phase 5 — Scaffold

One-shot generation of new repos, in-repo microservices, and publishable SDKs. Different from Phases 1–4 in two ways: scaffolds write to output_root (not .foundry-output/), and they're not incremental — they emit a complete tree, install, build, and report.

Owner: E11 Bootstrapper (agent-skill e11-bootstrapper).

Workflows in this phase

Code	Workflow	Purpose	Output
—	e11-bootstrap-wizard	Collect inputs, resolve the SDK matrix, hand off to a scaffold	wizard state at .foundry/_scaffold/wizard-state.yaml
[NB]	e11-scaffold-backend	New microservices backend repo	{output_root}/<project>/
[NF]	e11-scaffold-frontend-app	New shadcn-based React monorepo with e11-wired apps/web	{output_root}/<project>/
[NM]	e11-scaffold-microservice	Add an in-repo microservice (private, never published) to an existing backend	<repo>/microservices/service-<name>/
[AM]	e11-scaffold-microservice-package	Add a missing package (rest, tasks, functions, client, jobs) to an existing microservice	<repo>/microservices/service-<name>/<package>/
[NS] (backend)	e11-scaffold-sdk-backend	New publishable @engineering11/* backend SDK	your sdks-nodejs checkout
[NS] (frontend)	e11-scaffold-sdk-frontend	New publishable @engineering11/* frontend SDK	your sdks-react checkout
[NA]	e11-scaffold-app	New V2 app in the canonical app shape	<parent>/<app>/
[AS]	e11-scaffold-service	Add a V2 domain service — slices plus its permissions, guards, and role grants	<app>/microservices/service-<name>/ + deploy/ edits
[RI]	e11-bootstrap-wizard (resume)	Resume an interrupted wizard from saved state	continues from wizard-state.yaml

V1 or V2 — pick the right pair

The two platforms share vocabulary ("microservice", a microservices/ folder) and nothing else. Choosing wrong produces a scaffold that cannot build against the repo you're in, so the scaffolds detect it and refuse.

	V1 — [NB] / [NM] / [AM]	V2 — [NA] / [AS]
Source repo	sdks-nodejs	engineering11-platform
Packages	@engineering11/*	@engineering11/v2-*
Stack	NestJS, Firestore, Cloud Tasks, Yarn/Nx	Hono, Postgres/Kysely, Restate, pnpm
Service layout	service-<name>/{api,rest,tasks,functions,client,jobs}	service-<name>/{shared,core,data,rest,workflows,client}
Composition	per-service	one deploy/ composing every domain
Permissions	left to hand-written follow-up work	generated, guarded, catalogued, and granted

[AS] is the only scaffold that produces working authorization. It derives a permission vocabulary from a plain-language description of the domain, declares it once in the service's shared slice, guards every route with it, registers it in the platform permission catalog, and grants it to roles through the product map — then proves it by calling a guarded route as both a member (403) and an admin (200).

Standard flow

For the V1 scaffolds the wizard is the entry point; the menu codes pre-seed it with the right scaffold_type. The V2 scaffolds ([NA], [AS]) dispatch straight to the skill and collect their own inputs — [AS] in particular needs a conversation about the domain that the wizard's fixed prompts can't hold.

e11-bootstrapper → NB              ← or NF, NS, NM, AM
   │
   ▼
e11-bootstrap-wizard
   ├─ Step 1: Project identity (name, output_root)
   ├─ Step 2: SDK selection - skill:e11-knowledge matrix:unit,
   │           applies always + implies edges
   ├─ Step 3: Summary
   ├─ Step 4: [C] Confirm  ← nothing is written before this
   └─ Step 5: Hand off to the matching scaffold
                  │
                  ▼
              scaffold writes the tree, runs install + build
              (verify_command), reports success or failure.

If interrupted, invoke e11-bootstrapper again — it detects saved state at activation and offers resume/restart/cancel ([RI] jumps straight to resume). Multi-session scaffolds also keep a shared memlog at .foundry/_scaffold/.memlog.md.

How the scaffold skills are shaped

• Org defaults are overrides. Registry scope (npm_scope), verification commands (verify_command), starter SDK sets, and template knobs live in each scaffold's customize.toml — change them in .foundry/custom/<skill>.toml without touching skill files. See Customization.
• Resume is memlog-backed. Wizard state survives interruption and reinstalls.
• SDK scaffolds write to your checkout. They resolve the target repo via e11-sdks-nodejs / e11-sdks-react and refuse the shared cache — set FOUNDRY_SDKS_NODEJS_PATH / FOUNDRY_SDKS_REACT_PATH.
• V2 scaffolds generate from the Alloy corpus's platform knowledge — no clone, ever. The skills resolve query keys (foundation:v2-app-shape, app-assembly:canon-app:*, pattern:v2-domain-slice, pattern:v2-authz-catalog-and-seed, matrix:canon-env, matrix:published-surface) through skill:e11-knowledge, pinned by the project's .alloy/corpus.lock. Every scaffold-critical doc is stamped against the platform source and drift-gated in E11 CI; a key that does not resolve is a hard stop with a one-command fix (alloy corpus pin), deliberately — a stale copy is worse than a failed read, and Foundry never distributes the platform repo itself.

When to detour

• In-repo microservice vs publishable SDK. Internal business logic that won't be reused → [NM]. Reusable platform capability → [NS].
• Existing microservice missing a package (scaffolded api-only, now need rest) → [AM]; it never touches packages that are already there.
• Alloy not installed. The wizard reads matrix:unit from the corpus; without alloy it halts with an install instruction. npm install -D @engineering11/alloy and retry.
• output_root collision. Scaffolds refuse a non-empty target unless explicitly told otherwise.
• Need a doc site or other non-code scaffold. Out of scope — Phase 5 maps to E11 repos/SDKs/services.

After scaffolding

New backend repo → usually [NM] next, to add the first real service. New frontend app → jump into the normal phase flow ([PR] → [CA] → [SP] → …), or [DF] for small immediate changes.

Source

Workflow SKILL files:

• e11-bootstrapper/SKILL.md (the phase's agent-skill)
• e11-bootstrap-wizard/SKILL.md
• e11-scaffold-backend/SKILL.md · e11-scaffold-frontend-app/SKILL.md
• e11-scaffold-microservice/SKILL.md · e11-scaffold-microservice-package/SKILL.md
• e11-scaffold-sdk-backend/SKILL.md · e11-scaffold-sdk-frontend/SKILL.md
• e11-scaffold-app/SKILL.md · e11-scaffold-service/SKILL.md (V2) · knowledge layer: Knowledge layer — alloy + e11-knowledge