SQL Guidance Replaces the CRUD Template, and Workflow Tools Need ChatLoop

v1.50.0 replaces the SQL CRUD template and the skills built on it with guidance on how a microservice uses the sequel
package. It also fixes workflow tools on the two synchronous tool paths: llm.core's Chat and the MCP portal no
longer hand an LLM a workflow's graph in place of its result. Chat now rejects a workflow tool, the MCP portal no
longer lists workflows, and the ChatLoop workflow remains the way to give an LLM workflow tools.

Highlights

• SQL guidance replaces the CRUD template. The busstop template and the six sequel skills built on it are gone,
  and .claude/rules/sequel.txt is rewritten around the sequel package and the patterns that work well.
• yellowpages is a small example of a SQL-backed microservice: JSON endpoints, their REST counterparts, and the
  demo page.
• Chat rejects workflow tools with a 400. Run the conversation in ChatLoop to use one.
• The MCP portal exposes functions and web handlers only. Workflows are no longer listed as tools.

SQL Guidance Replaces the CRUD Template

The add-sql-microservice skill and its busstop template are removed, along with add-sql-fields,
modify-sql-fields, remove-sql-fields, rename-sql-object and rename-sql-table. The template generated close to
2,000 lines per microservice to generalize a pattern that does not fit every use case, and the follow-up skills
depended on its exact layout.

sequel.txt now describes how a microservice uses the sequel package directly: opening, migrating and closing the
database in OnStartup and OnShutdown, the per-test database and the telemetry wiring, where migrations live and how
to write them, writing portable queries, and exposing data through JSON and REST endpoints that run their SQL
directly. It closes with the recommended patterns: no joins across microservices, tenants, revisions, events, bulk
endpoints, opaque keys and reservations. Tests point at a real database server through SEQUEL_TESTING_DSN, which
tests read, not through config.local.yaml, which they do not. The rules now send an agent to sequel.txt as soon
as it adds a database to a microservice, not only once the microservice imports sequel.

A microservice scaffolded from the template is the project's own code. It keeps compiling and working unchanged, and
is now maintained by hand with sequel.txt as the guide.

yellowpages shrinks to match: the basic JSON endpoints, their REST counterparts on /persons, and the Demo page
the tour uses. Its migration creates a persons table under a new sequence, so a database the earlier version
migrated runs it too. Rows the earlier version stored in its person table are not carried over; the old table is
left in place, unused. The migration marks its statements -- DRIVER: mysql mariadb and -- DRIVER: pgx cockroachdb, since a MariaDB opened through a mariadb:// data source name skips a statement marked mysql
alone. The demo page's "GET by email" link now works: the page escaped the query in the path it relayed, so the request
went to a route that does not exist.

The review-microservice skill now flags a foreign key to, or a JOIN with, another microservice's tables.

Workflow Tools Need ChatLoop

An LLM tool can be a function, a web handler or a workflow, but only the ChatLoop workflow could ever run a workflow
tool, as a subgraph that parks the conversation until the child flow completes. The two synchronous paths posted the
workflow's URL like any other endpoint, and a workflow's URL returns its graph rather than running it. So on Chat,
and on the MCP portal's tools/call, the LLM got the graph's JSON as the tool's result, with no error.

Neither path runs workflows now, by design. A workflow is asynchronous: it can run for minutes or days, or wait on a
human. Chat and an MCP tool call are synchronous calls bounded by a time budget, which is 20s by default for a
request through the ingress. Running a workflow inside one would quietly turn it into a blocking call that fails when
the budget runs out, and leaves the flow running after the caller has gone.

• Chat fails with a 400, workflow tool requires ChatLoop, when any of its toolURLs resolves to a workflow,
  before the first turn. A ChatLoop flow, run through the foreman or as a subgraph from a task, still accepts
  workflow tools.
• The MCP portal turns only functions and web handlers into tools. Workflows are absent from tools/list, and a
  tools/call that names one returns [404] tool not found, like any unknown tool.

Other Changes

• Tool resolution is documented as strict. A tool URL the caller is not authorized for, or one that names a task
  or an outbound event, fails Chat, or InitChat and with it the ChatLoop flow. That was already the behavior;
  the llm.core notes and the workflow rules had said such tools were silently skipped.
• OpenAPI documents include tasks, so that inspectors such as Agent Studio can read their signatures. The rules
  had said tasks were filtered out. Consumers that build tools from the documents (llm.core, the MCP portal, the
  OpenAPI portal) keep their own list of the feature types they expose.
• Corrected rules and examples. The workflow rules' creditflow mock examples, and the creditflow example's
  test hint and design notes, now match the code. The rules give Chat's full signature.

Migration

From inside a Microbus project, ask Claude Code to upgrade Microbus:

Get the latest version of Microbus.

The upgrade-microbus skill tells you the sequel skills are gone. It offers to reword the Agent Instructions in the
CLAUDE.md of each microservice built from the template, which point at conventions sequel.txt no longer
describes. It also offers to replace the deprecated sequel.UnsafeSQL with a private marker type, where the package
that marks the values also builds the statements. Neither is required.

A Chat call whose toolURLs include a workflow's URL now fails with a 400. Such a call never ran the workflow, so
no working behavior is lost, but it compiles and fails only at run time. The skill finds the project's Chat calls,
traces their tool URLs to the workflows they name, and asks how to rewrite each one:

• from a workflow task, run the conversation as a ChatLoop subgraph,
  llmapi.NewSubgraph(flow).ChatLoop(ctx, provider, model, items, toolURLs, options);
• from a function or web handler, move the operation into a workflow that runs ChatLoop, or expose the logic the
  LLM needs as a function and pass that instead.

An MCP client that listed workflow tools no longer sees them.