# Strict Business Action Condition Fields Design

## Goal

Prevent generated business-action SQL from using a column that does not exist on the configured target table.

## Field Semantics

`requestFields` are request payload keys. `ruleChecks.conditionFields` and
`effects.conditionFields` are SQL condition columns and must exist on the
corresponding `targetTable`.

No alias mapping or legacy inference is supported. If a book table uses `id`,
the business blueprint must use `id` as its condition field. A related record
may still write that value into its own `book_id` column through
`${param.id}`.

## Validation

Business blueprint normalization and validation use a table-to-column map.
Every rule target field, effect target field, effect value key, and condition
field is checked against its own target table instead of the union of all
project columns.

Condition-based effects require explicit condition fields. The generator must
not fall back to all action request fields because request payloads can contain
fields that are not columns of the effect target table.

Invalid business blueprints fail before persistence and code generation with
an error naming the target table and invalid condition field.

## Generated Runtime

The Qing service implementation builds SQL directly from validated
`conditionFields`. It does not read `conditionColumns` and does not substitute
request fields when effect conditions are absent.

## Testing

Regression tests cover a schema where `book_info` has primary key `id` while
another table has `book_id`. A rule targeting `book_info` with
`conditionFields: ["book_id"]` must be rejected. A valid rule using `id` must
remain renderable as `where id = ?`.