Integration hooks

Say plainly that this baseline ships no integration, name the one scheduled task it does ship, and route the reader to the right skill before they invent a connector.

What the baseline guarantees

NOTHING integration-shaped ships in this composition. Zero integration activities, zero
endpoints, zero providers, zero job files, zero field-value conversion rules.
The only scheduled task any layer ships: feature-subscription-orders 1.1.1 writes ONE
ScheduledTask row, "Place recurring orders", bound to the DW-native
RecurringOrdersScheduledTask add-in, ** TaskEnabled = false **. DW registers the add-in TYPE
only; the row is layer-owned. Enable it to demo renewals.
The load-bearing architectural rule, before anyone models one: in DW10 an ERP is a SOURCE and
a TARGET in the Integration Framework. It is never a `ShopType=3` channel and never an
`EcomFeed`. Modelling it as a channel produces a demo that cannot show the thing the customer
is buying. Assert the rule as part of the gate: ZERO EcomShops rows and ZERO EcomFeed rows
for the ERP.
Three flavours exist (dw-demo-erp/SKILL.md:62 — note its own frontmatter says two):
a DB-staged one-direction mock (post-sync state pre-staged in the database plus a built-in
RESET scheduled task, no JSON files on disk), a two-directional mock built from four shipped
provider activities, and a live Business Central connector. Pick before building; they share
almost nothing.
One measured trap that will otherwise eat an hour: RunSqlScheduledTaskAddIn reports success
and silence identically. Never treat its run result as evidence — assert the effect.

Which skill covers it

dw-demo-erp (dynamo: false) — the owner of the source-AND-target rule and the three flavours.
references/integration-framework.md, references/erp-data-shape.md, references/mock-deltas.md,
references/two-way-mock.md, references/scenarios-first-planning.md.
dw-integration-framework (dynamo: true) — references/job-file-format.md,
references/provider-behaviour.md, references/custom-provider-authoring.md.
dw-integration-erp (dynamo: true, mcp: none) — references/ownership-split.md,
references/feed-keying.md.

Which MCP tools brand it

** Read this before planning tool calls. ** dw-integration-framework prescribes, in order
(SKILL.md:144-174):
  save_integration_endpoint -> test_integration_endpoint
  -> create_integration_activity
  -> get_integration_provider_schema -> save_integration_activity_mapping
  -> run_integration_activity -> get_integration_activity_status
  -> get_integration_activity_logs
  (+ get_integration_providers, get_integration_provider_parameters,
     get_integration_activities, get_integration_activity, get_integration_activity_mappings,
     get_integration_endpoints, schedule_integration_activity)
** None of those 15 tools exists in the Dynamicweb MCP add-in 0.4.4 tool set on this site. **
There is no tool whose name matches /integration/ at all. The MCP-expressible neighbours are:
  create_or_update_feeds, get_feeds, get_feed_providers, get_feed_queries   (outbound feeds)
  save_field_value_conversion_rules, get_field_value_conversions            (mapping tables)
  create_datasets / patch_datasets                                          (staged data)
Everything else is the admin UI (Settings > Integration > Activities) or the Management API.
Per the dynamo rule dw-integration-framework itself opens with, the correct move is to STOP
and name the admin screen — not to substitute a guessed HTTP call.
Job files are served anonymously and can carry credentials in <Password> elements. An install
destined for anything beyond a demo asserts zero occurrences of `Password=` under the decoded
job folder.

Verify

MCP: the tool list contains no name matching /integration/. Confirm with ToolSearch before
promising an integration beat.
For the shipped task: assert TaskName "Place recurring orders" with TaskEnabled false on a
clean baseline. There is no MCP read for ScheduledTask; that check is an admin-screen or SQL
read, which is itself the finding.
If an activity IS later built: never claim a run succeeded from a queued result. The log is
the evidence. And verify the ARTEFACT — the destination row count or the rendered page — not
the exit line: "Job succeeded" proves rows were processed, not that the effect exists.