@nanobpm/nano-workforce 0.72.0 → 0.73.0

package/AGENTS.md

@@ -117,6 +117,33 @@ GENERATED, never hand-edited.**
   that touch a shared process file into one; do **not** paper the collision over
   with a `dependsOn` edge added purely to serialise otherwise-parallel work.
 
+## Deploy by convention: `resources/` (ADR 0062)
+
+**Deployables live under `resources/` and deploy by convention — `nano.app.json`
+declares no `models`.** urban walks `resources/` (shallow, one level deep) and deploys
+every file: `resources/processes/*.bpmn`, `resources/forms/*.form`, and one prompt per
+task under `resources/prompts/*.md`.
+
+- **`resources/` is deploy-only.** Anything under it ships to the engine; anything
+  **outside** it never does. Docs therefore live under `docs/` (e.g.
+  `docs/agent-guide.md`) — put a `.md` in `resources/` only if you actually want it
+  deployed.
+- **No `models` block.** Rely on the convention; add a `models` override *only* for a
+  genuinely non-standard layout (nwf doesn't need one). An explicit `models` is used
+  verbatim and skips the convention walk.
+- **Basenames must be unique across the deploy set** — the deploy dedupe key is the
+  filename only, so two files sharing a basename in different dirs collide. `npm run
+  check:prompts` fails loudly on that.
+- **Agent prompts: linkedResource is the blessed *and only* path.** Each agent service
+  task links its base prompt with
+  `<zeebe:linkedResource resourceId="<token>.md" bindingType="latest" resourceType="GenericScript" linkName="prompt"/>`,
+  which the engine resolves to the latest deployed `resources/prompts/<token>.md` at job
+  activation, combined at runtime with the per-task `appendPrompt` FEEL. `bindingType="latest"`
+  lets a prompt update land mid-epic without a process redeploy.
+- **Deploy-time `{{token}}` templating is removed — no back-compat.** To inject a per-run
+  value (URL, flag) into an agent, pass it as a runtime job variable / `appendPrompt`
+  FEEL; never bake it into a model at deploy time.
+
 ## Engine capabilities (Zeebe parity — use them, don't work around them)
 
 The nanobpmn engine (`~/workspace/nanobpmn` `engine-core`, deployed via the nano
@@ -247,7 +274,7 @@ npm run lint                                          # biome check (incl. ban-`
 npm run typecheck                                     # tsc --noEmit (Node)
 npm run check                                         # urban check (manifest validation)
 npm run layout:check                                  # BPMN diagram freshness (no drift)
-npm run check:prompts                                 # agent-prompt template resolution
+npm run check:prompts                                 # agent-prompt linkedResource resolution
 npm run check:migrations                              # migration prefixes (no collisions)
 npm run check:contracts                               # contract registry (no synonyms / undeclared env keys)
 npm test                                              # unit tests (node --test)

package/CHANGELOG.md

@@ -1,3 +1,17 @@
+# [0.73.0](https://github.com/nanobpm/nano-workforce/compare/v0.72.1...v0.73.0) (2026-08-15)
+
+
+### Features
+
+* **deploy:** resources/ deploy-by-convention; drop models; docs→docs/ (ADR 0062 step 3) ([#241](https://github.com/nanobpm/nano-workforce/issues/241)) ([9f7f85c](https://github.com/nanobpm/nano-workforce/commit/9f7f85c1231ce228c4468ac8f5222dd14d84022b)), closes [nanobpm/nano-ide#244](https://github.com/nanobpm/nano-ide/issues/244) [#244](https://github.com/nanobpm/nano-workforce/issues/244) [#239](https://github.com/nanobpm/nano-workforce/issues/239) [nanobpm/nano-ide#244](https://github.com/nanobpm/nano-ide/issues/244) [nanobpm/nano-workforce#239](https://github.com/nanobpm/nano-workforce/issues/239)
+
+## [0.72.1](https://github.com/nanobpm/nano-workforce/compare/v0.72.0...v0.72.1) (2026-08-15)
+
+
+### Bug Fixes
+
+* remove question from table ([#240](https://github.com/nanobpm/nano-workforce/issues/240)) ([d672206](https://github.com/nanobpm/nano-workforce/commit/d6722063c3110672f8e2f0ee8c955c7ab0b39577))
+
 # [0.72.0](https://github.com/nanobpm/nano-workforce/compare/v0.71.0...v0.72.0) (2026-08-15)
 
 

package/README.md

@@ -156,8 +156,8 @@ capability):
 
 - `--command 'copilot -p - --allow-all-tools'` starts the Copilot CLI reading its
   prompt from **stdin** (`-p -`). The harness pipes the whole job JSON (prompt +
-  `job.variables`) to stdin; the relevant `prompts/*.md` resource (linked into the task
-  and fetched by the harness at activation) tells the agent how
+  `job.variables`) to stdin; the relevant `resources/prompts/*.md` resource (linked into
+  the task and fetched by the harness at activation) tells the agent how
   to read it and where to write its result.
 - **`--allow-all-tools` is essential** for an unattended worker — without it Copilot
   pauses for permission before each tool call and the job stalls.
@@ -351,14 +351,15 @@ agent's base prompt is **not** in the job payload — it is delivered as a
 **linked resource** (likewise `plan.md`, `feature.md`, `fix-ci.md`, …):
 
 ```xml
-<zeebe:linkedResource resourceId="review-round.md" bindingType="latest" linkName="prompt"/>
+<zeebe:linkedResource resourceId="review-round.md" bindingType="latest" resourceType="GenericScript" linkName="prompt"/>
 ```
 
-that the engine resolves to the latest deployed `prompts/*.md` at job
-activation (the prompts deploy as generic resources via a `models` glob in
-`nano.app.json`); per-instance context (e.g. a human's escalation answer) is appended
-by the harness. Because the binding is `latest`, redeploying one `prompts/*.md` updates
-the prompt for the next activation in a **running** epic — see SPEC §9.
+that the engine resolves to the latest deployed `resources/prompts/*.md` at job
+activation (the prompts deploy as generic resources under the `resources/` deploy-by-
+convention layout — `nano.app.json` declares no `models`; ADR 0062); per-instance context
+(e.g. a human's escalation answer) is appended
+by the harness. Because the binding is `latest`, redeploying one `resources/prompts/*.md`
+updates the prompt for the next activation in a **running** epic — see SPEC §9.
 
 ---
 

package/SPEC.md

@@ -65,11 +65,13 @@ nano-workforce/
   resources/
     processes/
       convergence-loop.bpmn   # the durable convergence process
+    prompts/
+      review-round.md         # agent instructions asset (deployed by the resources/ convention)
   db/
     migrations/
       001_init.sql            # sqlite schema
-  prompts/
-    review-round.md           # agent instructions asset (injected into job data)
+  docs/
+    agent-guide.md            # operator guide (docs live OUTSIDE resources/ — never deployed)
   components/
     review-round.json         # Zeebe element template for the senior:pr-review service task
   SPEC.md                     # this document
@@ -155,8 +157,8 @@ Notes:
 
 The base instructions are **not** a job variable: they are delivered as a
 **linked resource** on the `senior:pr-review` task —
-`<zeebe:linkedResource resourceId="review-round.md" bindingType="latest" linkName="prompt"/>`,
-which the engine resolves to the latest deployed `prompts/review-round.md` at job
+`<zeebe:linkedResource resourceId="review-round.md" bindingType="latest" resourceType="GenericScript" linkName="prompt"/>`,
+which the engine resolves to the latest deployed `resources/prompts/review-round.md` at job
 activation.
 
 **Output** (job result variables):
@@ -178,7 +180,7 @@ gives **each job its own `mkdtemp` run-dir + fresh clone**, runs the agent with
 **reaps that run-dir when the job ends**. So multiple agents on one host do **not**
 collide even in host mode — the isolation lives below the agent.
 
-Consequences the prompt (`prompts/review-round.md`) encodes:
+Consequences the prompt (`resources/prompts/review-round.md`) encodes:
 - The agent works only inside its provided `cwd`; it must **not** re-clone or create
   a separate `git worktree`, and must not touch global/host state.
 - The agent **cleans up anything it creates outside the commit** before returning
@@ -300,25 +302,26 @@ when the engine data is purged, to keep app state and engine state consistent).
 
 ## 9. Prompt delivery — linked resources (`bindingType: latest`)
 
-Each agent task's base prompt lives **only** in its `prompts/*.md` side-car, deployed
-as a **generic resource** and **linked** — not baked — into the model (issue #169).
-`nano.app.json` lists `prompts/*.md` in a `models` deploy glob, so `@nanobpm/urban`
+Each agent task's base prompt lives **only** in its `resources/prompts/*.md` side-car,
+deployed as a **generic resource** and **linked** — not baked — into the model (issue
+#169). Under the ADR 0062 `resources/` deploy-by-convention layout, `nano.app.json`
+declares **no `models`**, so `@nanobpm/urban` walks `resources/` (shallow, one level) and
 deploys each file as an `application/octet-stream` resource whose deployed **name is
-the file's basename** (`prompts/review-round.md` → resource `review-round.md`). Each
-agent service task links it:
+the file's basename** (`resources/prompts/review-round.md` → resource `review-round.md`).
+Each agent service task links it:
 
 ```xml
 <zeebe:linkedResources>
-  <zeebe:linkedResource resourceId="review-round.md" bindingType="latest" linkName="prompt" />
+  <zeebe:linkedResource resourceId="review-round.md" bindingType="latest" resourceType="GenericScript" linkName="prompt" />
 </zeebe:linkedResources>
 ```
 
 At **job activation** the engine resolves the *latest deployed* key for that
 `resourceId` and hands the content to the harness in the `linkedResources` activation
 header; the harness fetches by key and uses it as the base prompt. Because the binding
-is `latest`, **redeploying a single `prompts/*.md` changes the prompt for the next task
-activation in a running epic** — no process redeploy, no in-flight epic restart. This
-is the live-prompt debugging loop: edit one Markdown file, `urban deploy` (or restart
+is `latest`, **redeploying a single `resources/prompts/*.md` changes the prompt for the
+next task activation in a running epic** — no process redeploy, no in-flight epic restart.
+This is the live-prompt debugging loop: edit one Markdown file, `urban deploy` (or restart
 the app, which deploys on boot), and the next agent job of that type picks it up.
 
 > **Latest-for-now, audited.** The engine currently keeps only the latest version per
@@ -332,7 +335,8 @@ the app, which deploys on boot), and the next agent job of that type picks it up
 > `resourceId` is dropped from the activation header (no incident) — the agent would
 > then run prompt-less. `scripts/check-agent-prompts.ts` (CI gate `check:prompts`)
 > guards against this: every `linkName="prompt"` link's `resourceId` must match a
-> prompt file the app actually deploys (a file in a `models` deploy glob), each linked
+> prompt file the app actually deploys (a file under the `resources/` convention walk, or
+> a manifest `models` override glob), each linked
 > prompt must be non-blank and teach the agent to emit a machine-readable result
 > (`$AGENT_RESULT_FILE` / `::nano:result::`), and no task may still carry the retired
 > baked `io.nanobpm.agentTask.task.prompt` header.
@@ -344,7 +348,8 @@ the linked base — the model owns any separator, and a null/empty append leaves
 untouched. Base prompts can't be composed in FEEL (they are quote-heavy, and XML
 attribute escaping would corrupt a FEEL string literal), so composition happens via
 this append seam rather than inline in FEEL. Requires an `@nanobpm/urban` deploy that
-emits generic-resource deployments for `prompts/*.md` and a harness that consumes
+deploys the `resources/` convention (generic-resource deployments for
+`resources/prompts/*.md`) and a harness that consumes
 `linkedResources` and fetches the resource by key.
 
 ## 10. Poller
@@ -554,7 +559,7 @@ the loop runs one parallel `implement` MI fan-out per wave:
   its prerequisites have **landed on the base branch** — not merely opened. This lets
   a blocking prerequisite (e.g. app scaffolding) fully converge and merge before the
   next wave builds on it. `gate_wave` lives in `db/migrations/007_wave_gate.sql`.
-- **Adopting a decomposed epic** (`prompts/plan.md` Step 0): when adopting existing
+- **Adopting a decomposed epic** (`resources/prompts/plan.md` Step 0): when adopting existing
   sub-issues, the planner honours an explicit `Depends-on: #N` / `Blocked by #N`
   directive in a sub-issue body, mapping each prerequisite `#M` to `issue-M` in the
   adopted task's `dependsOn` — so a human-declared blocking order survives adoption.

package/app/agentGuide.ts

@@ -1,7 +1,8 @@
 // The agent operator guide served by GET /app/api/agent (operationId `getAgentInstructions`).
 //
-// The guide itself is authored as plain markdown in `resources/agent-guide.md` (kept out of
-// `prompts/` so it is NOT treated as a deployable agent template) and read from the checkout at
+// The guide itself is authored as plain markdown in `docs/agent-guide.md` (kept OUT of
+// `resources/` so the deploy-by-convention walk does NOT treat it as a deployable model — docs
+// live under `docs/`, ADR 0062) and read from the checkout at
 // module load — same "run the .ts sources directly, inspect the working tree at runtime" approach
 // as version.ts. Two placeholders are substituted per request/deployment so the embedded examples
 // are copy-pasteable against THIS instance:
@@ -15,7 +16,7 @@ import { dirname, join } from "node:path";
 import { fileURLToPath } from "node:url";
 
 const REPO_ROOT = dirname(dirname(fileURLToPath(import.meta.url)));
-const GUIDE_PATH = join(REPO_ROOT, "resources", "agent-guide.md");
+const GUIDE_PATH = join(REPO_ROOT, "docs", "agent-guide.md");
 
 // Read the raw guide once, at module load. Frozen for the life of the process.
 const RAW_GUIDE: string = (() => {

package/app/feature.ts

@@ -248,7 +248,7 @@ export function deriveFeatureBlockedPatch(
 export const featureRuns = (data: DataLayer) => data.table<FeatureRun>("feature_runs", "feature_key");
 
 /** The deterministic task id for a single-issue run — the implementation agent branches
- * `feat/<task.id>` (see prompts/feature.md), so it MUST be derivable from the issue alone
+ * `feat/<task.id>` (see resources/prompts/feature.md), so it MUST be derivable from the issue alone
  * and stable across a resume. The PR is opened on the target repo, so the issue number
  * alone is unambiguous within it. */
 export function featureTaskId(issueNumber: number): string {
@@ -321,7 +321,7 @@ export async function startFeature(
       issueNumber: parsed.number,
       issueUrl: parsed.url,
       // The single slice the implementation agent builds. `task.prompt` is its primary instruction
-      // (prompts/feature.md); `task.id` fixes its deterministic branch `feat/<task.id>` across a
+      // (resources/prompts/feature.md); `task.id` fixes its deterministic branch `feat/<task.id>` across a
       // resume. Unlike an epic, there is no planner — the whole issue IS the slice.
       task: {
         id: featureTaskId(parsed.number),
@@ -337,7 +337,7 @@ export async function startFeature(
       converge,
       autoMerge,
       // A single-issue feature run OWNS its issue (the whole issue is the slice), so the agent may
-      // claim it with a "starting work" comment on a first run (prompts/feature.md). Epic slices
+      // claim it with a "starting work" comment on a first run (resources/prompts/feature.md). Epic slices
       // (plan-fanout) deliberately DO NOT set this — their `issue` is the shared parent epic, which
       // must never be claimed per-slice.
       claimIssue: true,

package/app/plan.ts

@@ -31,8 +31,10 @@ export const ESCALATION_SLA_TIMEOUT = escalationSlaTimeout(
 const now = () => new Date().toISOString();
 
 // Agent prompts are no longer read by the host. The `senior:plan`, `senior:plan-review`, and
-// `senior:feature` prompts are generic resources (`prompts/plan.md` / `prompts/plan-review.md` /
-// `prompts/feature.md`, deployed via a `models` glob in nano.app.json) linked into each task as
+// `senior:feature` prompts are generic resources (`resources/prompts/plan.md` /
+// `resources/prompts/plan-review.md` / `resources/prompts/feature.md`, deployed under the
+// `resources/` deploy-by-convention layout — nano.app.json declares no `models`) linked into each
+// task as
 // `<zeebe:linkedResource … bindingType="latest" linkName="prompt"/>` and resolved by the engine at
 // job activation. Per-instance dynamic context (a plan's rejection findings, a task's brief) rides
 // `appendPrompt`, which the harness concatenates onto the linked base. The host only carries
@@ -244,7 +246,7 @@ export function normalizeBaseBranch(input: string | null | undefined): string {
 
 /** The per-instance brief appended to an implementer agent's prompt when the plan pins a base
  * branch. It is authoritative over the static "branch off the default branch" wording in
- * prompts/feature.md, so the agent branches off — and opens its PR against — the integration
+ * resources/prompts/feature.md, so the agent branches off — and opens its PR against — the integration
  * branch, and reads the epic's latest landed state there rather than the repo default branch. */
 export function renderBaseBranchBrief(baseBranch: string): string {
   return [

package/app/service.ts

@@ -111,7 +111,8 @@ export const MERGE_ADMIN = ["1", "true", "on", "yes"].includes(
 );
 
 // The `senior:pr-review` agent prompt is no longer read by the host: it is a generic resource
-// (`prompts/review-round.md`, deployed via a `models` glob in nano.app.json) linked into the task
+// (`resources/prompts/review-round.md`, deployed under the `resources/` deploy-by-convention layout
+// — nano.app.json declares no `models`) linked into the task
 // as `<zeebe:linkedResource resourceId="review-round.md" bindingType="latest" linkName="prompt"/>`
 // and resolved by the engine at job activation. The host only carries runtime PR identity + the
 // round counter now.

package/app/taskDelta.ts

@@ -1,6 +1,6 @@
 // nano-workforce — structured scope/impl-change report from implementers (D5, issue #55 / #49).
 //
-// The implementer result contract (prompts/feature.md) can carry an optional `delta`: a machine-
+// The implementer result contract (resources/prompts/feature.md) can carry an optional `delta`: a machine-
 // readable record of how a slice's implementation diverged from its brief — a changed contract, a
 // discovered constraint, files it now touches beyond its slice, or other tasks it affects. Before
 // this, that information lived only in PR prose: invisible to the planner, to sibling agents, and

package/{resources → docs}/agent-guide.md

@@ -307,20 +307,29 @@ both live in the source repo, not in the job payload.
   `retro.bpmn`. These are the source of truth for routing. To understand *why* an
   instance went where it did, read the gateway conditions (FEEL expressions on the
   sequence flows) for the element it is parked on (§5).
-- **Prompts (agent base instructions):** `prompts/*.md` — `review-round.md`,
-  `plan.md`, `feature.md`, `fix-ci.md`, `rebase.md`, `trial-merge.md`, etc. An
-  agent's base prompt is **not** a job variable: it is delivered as a
-  **linked resource** (likewise `plan.md`, …):
+- **Prompts (agent base instructions):** `resources/prompts/*.md` — `review-round.md`,
+  `plan.md`, `feature.md`, `fix-ci.md`, `rebase.md`, `trial-merge.md`, etc. They live
+  under `resources/` so they deploy by convention (ADR 0062 — the app declares no
+  `models`; every file under `resources/` is deployed, one `.md` per task under
+  `resources/prompts/`). An agent's base prompt is **not** a job variable and is **not**
+  a deploy-time `{{token}}` substitution (that templating is removed — there is no
+  back-compat): it is delivered as a **linked resource**, the blessed **and only**
+  prompt-modularity path:
 
   ```xml
-  <zeebe:linkedResource resourceId="review-round.md" bindingType="latest" linkName="prompt"/>
+  <zeebe:linkedResource resourceId="review-round.md" bindingType="latest" resourceType="GenericScript" linkName="prompt"/>
   ```
 
   that the engine
-  resolves to the latest deployed prompt at job activation. Because the binding is
-  `latest`, redeploying one of these files updates the prompt mid-epic without a process
-  redeploy. If an agent misbehaves systematically, the prompt is the first thing
-  to inspect/fix.
+  resolves to the latest deployed prompt at job activation, combined at runtime with the
+  per-task `appendPrompt` FEEL (the task-specific slice appended to this base). Because
+  the binding is `latest`, redeploying one of these files updates the prompt mid-epic
+  without a process redeploy. If an agent misbehaves systematically, the prompt is the
+  first thing to inspect/fix.
+
+  > **Value-injection caveat:** never bake a per-run value (a URL, a flag) into a prompt
+  > at deploy time — that path is gone. Pass it as a runtime job variable / `appendPrompt`
+  > FEEL instead; deploy-time string substitution is not available.
 - **Job contract:** `senior:pr-review` receives `{ prUrl, repo, prNumber, round,
   answer? }` and must return a flat result `{ status, summary, question? }` with
   `status ∈ { converged, addressed, waiting, needs_input, blocked }`. A round that
@@ -329,7 +338,7 @@ both live in the source repo, not in the job payload.
   rather than escalating.
 
 To validate a model/prompt change locally: `npm run layout:check` (BPMN diagram
-freshness), `npm run check:prompts` (every template resolves), `npm run check`
+freshness), `npm run check:prompts` (every prompt link resolves), `npm run check`
 (manifest), `npm run typecheck`, `npm run lint`, `npm test`.
 
 ---

package/e2e/agent-answerable.e2e.ts

@@ -25,6 +25,7 @@ import { fileURLToPath } from "node:url";
 import type { EngineJob } from "@nanobpm/urban/runtime";
 import { bootTestApp, type TestApp } from "@nanobpm/urban-testkit";
 import { admitGithubState, installAdmitGithub } from "./support/github-admit.ts";
+import { asEngineClient } from "./support/engine-client.ts";
 import {
   completeEscalationAsAgent,
   latestCompletion,
@@ -138,7 +139,7 @@ describe("agent-answerable escalations (U6 — same form, agent completer, attri
 
         // Complete AS AN AGENT through the host-side completer — the same typed `{resolution, answer}`
         // a human submits through the inbox, only the caller differs.
-        const r = await completeEscalationAsAgent(app.db, app.engine, {
+        const r = await completeEscalationAsAgent(app.db, asEngineClient(app.engine), {
           userTaskKey: task.userTaskKey,
           agentId: "senior:answer-bot",
           variables: { resolution: "answer", answer: "use v2" },

package/e2e/feature-run.e2e.ts

@@ -22,6 +22,7 @@ import { fileURLToPath } from "node:url";
 import type { EngineJob } from "@nanobpm/urban/runtime";
 import { bootTestApp, type TestApp } from "@nanobpm/urban-testkit";
 import { admitGithubState, installAdmitGithub } from "./support/github-admit.ts";
+import { asEngineClient } from "./support/engine-client.ts";
 import { pollFeatureBlocked, pollFeatureEscalations } from "../app/service.ts";
 
 const APP_ROOT = resolve(dirname(fileURLToPath(import.meta.url)), "..");
@@ -192,7 +193,7 @@ describe("single-issue feature run (#172 — feature.bpmn)", () => {
 
         // The poller fills in the completable user-task key (which no service task can know — the task
         // doesn't exist yet when record-feature runs) so the pages can drive an attributed acknowledge.
-        await pollFeatureBlocked(app.db, app.engine);
+        await pollFeatureBlocked(app.db, asEngineClient(app.engine));
         const denorm = await featureRow(app, featureKey);
         assert.ok(denorm.blocked_user_task_key, "the poller denormalised the completable blocked user-task key");
         assert.equal(denorm.status, "awaiting_operator", "the run stays awaiting_operator while parked");
@@ -214,7 +215,7 @@ describe("single-issue feature run (#172 — feature.bpmn)", () => {
         assert.equal(settled.blocked_user_task_key, null, "the completable-task pointer was cleared on ack");
 
         // A further poll pass is an idempotent no-op — a terminal run is not a candidate.
-        await pollFeatureBlocked(app.db, app.engine);
+        await pollFeatureBlocked(app.db, asEngineClient(app.engine));
         assert.equal((await featureRow(app, featureKey)).status, "blocked");
       },
     );
@@ -297,7 +298,7 @@ describe("single-issue feature run (#172 — feature.bpmn)", () => {
 
         // The poller fills in the completable user-task key (which the service task can't know — the
         // task doesn't exist yet when it runs) so the UI can drive an attributed answer.
-        await pollFeatureEscalations(app.db, app.engine);
+        await pollFeatureEscalations(app.db, asEngineClient(app.engine));
         const escalated = await featureRow(app, featureKey);
         assert.ok(escalated.escalation_user_task_key, "the poller denormalised the completable user-task key");
         assert.equal(escalated.status, "escalated", "the run stays escalated while parked");
@@ -324,7 +325,7 @@ describe("single-issue feature run (#172 — feature.bpmn)", () => {
         assert.equal(settled.escalation_question, null, "the surfaced question was cleared once resolved");
 
         // A further poll pass is an idempotent no-op — a terminal run is not a candidate.
-        await pollFeatureEscalations(app.db, app.engine);
+        await pollFeatureEscalations(app.db, asEngineClient(app.engine));
         assert.equal((await featureRow(app, featureKey)).status, "opened");
       },
     );

package/e2e/support/engine-client.ts

@@ -0,0 +1,17 @@
+import type { EngineClient } from "@nanobpm/urban";
+import type { TestApp } from "@nanobpm/urban-testkit";
+
+// urban 0.49.0 (ADR 0062) added `EngineClient.getForm`, but the published
+// @nanobpm/urban-testkit (0.4.0) predates it, so its `WasmEngineClient` neither
+// declares nor implements the method. These hermetic e2e flows drive user-task
+// completion directly (`completeUserTask`) and never resolve a form schema, so we
+// complete the contract with a null-returning `getForm` — the documented "no
+// matching form" path — until a testkit release catches up with urban's engine
+// seam. Scoped to the test harness; production adapters implement `getForm` for real.
+export function asEngineClient(engine: TestApp["engine"]): EngineClient {
+  const e = engine as unknown as EngineClient & { getForm?: EngineClient["getForm"] };
+  if (typeof e.getForm !== "function") {
+    e.getForm = async () => null;
+  }
+  return e;
+}

package/nano.app.json

@@ -4,15 +4,6 @@
   "id": "nano-workforce",
   "name": "Nano Workforce",
   "codename": "nano-workforce",
-  "models": {
-    "processes": [
-      "resources/processes/*.bpmn",
-      "prompts/*.md"
-    ],
-    "forms": [
-      "resources/forms/*.form"
-    ]
-  },
   "data": {
     "default": "app",
     "sources": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nanobpm/nano-workforce",
-  "version": "0.72.0",
+  "version": "0.73.0",
   "description": "Nano Workforce — an Agent Graph Orchestration application for Agentic SDLC: durable BPMN processes that coordinate a graph of AI agents across the software delivery lifecycle.",
   "type": "module",
   "main": "main.ts",
@@ -53,11 +53,11 @@
   },
   "dependencies": {
     "@nanobpm/agentic": "^0.1.0",
-    "@nanobpm/urban": "^0.48.0"
+    "@nanobpm/urban": "^0.50.0"
   },
   "devDependencies": {
     "@biomejs/biome": "^2.4.11",
-    "@nanobpm/urban-testkit": "^0.4.0",
+    "@nanobpm/urban-testkit": "^0.5.0",
     "@semantic-release/changelog": "^6.0.3",
     "@semantic-release/git": "^10.0.1",
     "@semantic-release/npm": "^13.1.5",